You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some situations, such as generating protocol shapes (not limited to, but in particular: traits), it would be beneficial to allow evolving models without breaking binary compatibility of generated code.
For example, adding a new field to a struct trait shouldn't break binary compatibility of the result.
We should come up with and agree on:
conditions under which we would generate a shape as bincompat-friendly
for example: all traits? per-namespace/per-shape configuration? Something like what we're doing for validated newtypes in Validated newtypes #1454?
an exact encoding that'll work across all supported Scala versions. Some starting points for discussion:
non-case classes
public getters
public withX (for a member named x) instead of copy methods
mutable builders?
and implement these for the next minor version (0.19), if possible.
The text was updated successfully, but these errors were encountered:
I won't write down the exact encoding just yet (I changed my mind several times in the last couple hours), but it appears that we'll draw a lot of inspiration from Contraband, including a @since("1.0") trait (or similar) to allow marking new members as having been added in a particular version.
If there's a bunch of versions, we can generate a constructor / apply for each of them, e.g.
//assume everything is requiredstructureFoo {
s1: String
@since("1.0") s2: String="test2"
@since("1.0") s3: String="test3"s4: String
}
// we can add these traits for external shapes too, with `apply`applyFoo$s4@since("2.0")
applyFoo$s4@default("test4")
I'll play with Contraband soon to see if it does this (and other interesting cases it handles, such as adding new values between existing ones) and get back with an update.
Related: #1485, smithy-lang/smithy#2243, Discord discussion
In some situations, such as generating protocol shapes (not limited to, but in particular: traits), it would be beneficial to allow evolving models without breaking binary compatibility of generated code.
For example, adding a new field to a struct trait shouldn't break binary compatibility of the result.
We should come up with and agree on:
withX
(for a member namedx
) instead of copy methodsand implement these for the next minor version (0.19), if possible.
The text was updated successfully, but these errors were encountered: