Generate Getters Proposal Of Generation

[pyrohedgehog]

After brief discussion in the discord. This is a quick draft around an idea of getters. Allowing interfaces to be used to accept arbitrary generated models more easily. The generated files have been edited by hand to quickly show a concept!

The main goal of this is, to be able to have more easily reusable components between models. In this case, say I wanted a single method that can take in an ID, and a Status, that would fit both Order, or Pet.

Now

with the current system, I would need to copy these fields into a hand written common type, having functionally identical code.

My Idea

By having getters, we could take the generated code, and create a simple interface like

type IdentifiableStatusItem interface{
    GetID() int64
    GetStatus() string
}

and use the interface to handle our shared values.

Why not composite types?

scary
While we could have a common generated type

type IdentifiableStatus struct{
    ID int64
    Status string
}
type Pet struct{
    IdentifiableStatus
    ...
}

it seems more complicated to implement, changing core generation patterns, and currently, would not be able to call aPet.ID. Some day being able to call struct literals such as aPet.ID is (hopefully) coming soon,, and that could make backwards compatibility easier, A) that seems far more complicated, and B) would rely on the newer go version to be implemented.

[fredbi]

@pyrohedgehog that's entirely doable but here are a few questions and/or caveats.

1. I assume that this is just an option to models, and this is not going to affect how the generated server/client interact with the models
2. We already have getters when we generate an interface for polymorphic types (i.e. with discriminator), but this follows a different convention: private field, e.g; "id string" vs getter "ID() string". I think your addition should be reserved to concrete types.
3. As always, more methods means more possibilities to generate conflicting names: e.g. schema {"id": {"type":"string"},"getId":{"type":"string} would conflict and fail to generate code that compiles - so either we accept that limitation or we try hard to deconflict.
4. other conflict situation: we have composition with AllOf. a field call id in one schema and a field called getId in another one. The allOf composition (embedded types) would shadow GetID() in a difficult to predict way
5. It is restricted to schemas of type "object" that are not interfaces, not maps, not a io.Reader, not an external type, not an alias type
6. Similarly this would work with concrete fields but not sure about additional properties (GetAdditionalProperties()?)

The right place in the generator templates is templates/schema.gotmpl. We typically have there an optional method generation for MarshalBinary methods.