RFR: JEP 360: Sealed Types (Preview)

[Kłeczek, Michał]

On 15/04/2020 16:22:48, "Brian Goetz" <brian.goetz at oracle.com> wrote:

>
>>Actually I was talking about _adding_ a new permitted subtype (and this is why I think it might be surprising and worth mentioning):
>
>Yep, already covered that in my reply:
>
>  " If its a matter of having added a permitted subtype, the change is also easy; if you don't want to handle the new case, add a default clause that throws (which is what you would have done in the first place if you didn't have the option to lean on exhaustiveness checking in the compiler.)"
I think this is missing the point:
it is not about what the client can do - it is about a library developer 
designing the library API so that it can be changed in the future.

I think it is worthwhile to warn library developers that exposing sealed 
types with public-only permitted subtypes is a one-way street - no 
non-breaking change to this API is possible in the future.

>
>
>
>>
>>// Maintenance domain B built against A 1.0
>>int z = switch (x) {
>>     case A a: ...
>>     case B b: ...
>>     // no default
>>     // boom
>>}
>
>Yes, this is exactly the case I was talking about.   I think we should be happy for the "boom"; it alerts us to the fact that we've tightly coupled to something we don't control.  And the remediation is easy; either handle it (which might be work), or throw when we see the novel value (either with a default, or probably better, with an explicit `case C`.)  And the throwing is what we would have been forced to write before without the sealing information.
>
>>Given the fact that removal of a permitted subtype is also an incompatible change (since either a public type is removed or it can no longer be a subtype of the same sealed supertype) - it means the set of permitted types has to be set in stone.
>
>The "set in stone" part is where I think you've overstated your case.  There's a flexible range of choices here, but there are both costs and benefits for each of them.
I am really interested in learning these choices as a library developer.
How I can modify previously exposed permitted subtypes list _without 
forcing library clients to do anything when upgrading_ (ie. make the 
change compatible and allow drop-in replacement of my library old 
version).

Thanks,
Michal