Closed bflad closed 1 year ago
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Description
Currently the specification relies on a single string value to declare a necessary code import for a piece of code. In practice though, package naming can overlap and require using programming language features such as import aliasing. While generators could generally support aliasing within the string itself to match language conventions, it would be more expressive if the specification was more explicit about the correct way to handle this coding issue.
Proposal
In the specification, create a new shared object definitions:
In the specification, where an import is defined as single string value, migrate to new definition:
In the specification, where import is defined as an array of string values, migrate to new definition:
In the Go bindings, create a new
code
package andImport
type:Update
Import
/Imports
fields in other types to use newcode.Import
type.