Skip to content
This repository has been archived by the owner on Dec 8, 2018. It is now read-only.

Type-references from generated code in another package #7

Open
dpolansky opened this issue Feb 20, 2017 · 1 comment
Open

Type-references from generated code in another package #7

dpolansky opened this issue Feb 20, 2017 · 1 comment

Comments

@dpolansky
Copy link
Owner

Consider the following code:

typeRef := TypeReferenceFromInstance(bytes.Buffer{})
actual := typeRef.GetName()

actual will be assigned bytes.Buffer as the name, which contains the package qualifier as expected.

However, the TypeReference for generated specs (such as a StructSpec or InterfaceSpec) will not have a package qualifier because we don't know the package it belongs to until it is added to a FileSpec:

strSpec := NewStructSpec("Foo")
// strSpec.GetName() would return "Foo"

file := NewFileSpec("mypackage").CodeBlock(strSpec)

Consider the use case of getting a TypeReference to strSpec from another package. In this example, Foo belongs to package mypackage, and it is used in a function myFunc in package main:

strSpec := NewStructSpec("Foo")
mypackageFile := NewFileSpec("mypackage").CodeBlock(strSpec)

// we pass in strSpec as a TypeReference to use it as a result parameter
func := NewFuncSpec("myFunc").ResultParameter("", strSpec)
mainFile := NewFileSpec("main").CodeBlock(func)

Currently, the TypeReference for strSpec would only include its unqualified name, 'Foo'. I propose adding a method to a FileSpec that wraps a TypeReference with the File's package name:

strSpec := NewStructSpec("Foo")
mypackageFile := NewFileSpec("mypackage").CodeBlock(strSpec)
wrappedStrSpec := mypackageFile.WrapTypeReference(strSpec)

func := NewFuncSpec("myFunc").ResultParameter("", wrappedStrSpec)
mainFile := NewFileSpec("main").CodeBlock(func)

When wrappedStrSpec.GetName() is called, it returns mypackage.Foo.

Any suggestions / alternative approaches for using generated TypeReferences in other packages?

@kdeenanauth Would love to hear your thoughts on this!

@kdeenanauth
Copy link
Collaborator

It seems like a good idea. Especially as a stop gap to a bigger refactor @bmoylan outlined we would need to consistently resolve all of the issues.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants