RFR: JEP 360: Sealed Types (Preview)

[Ty Young]

On 4/14/20 12:54 AM, Jonas Konrad wrote:
>
>
>> This may be a bit unfair of a question given how in-development
>> everything is but... has anyone actually tried converting an existing
>> project of reasonable size and complexity to use inline types and/or
>> records(AKA more then Point)? Has anyone considered the negative
>> implications on people writing higher-level abstractions over inlined
>> types?
> Records, along with sealed types, are already present and in use in other lamguages. From my own experience they are extremely useful there. For sealed types in particular they can replace systems that would need complicated visitor patterns with much more concise pattern matching.
>
> I think you are also missing the point of this a little. When you develop programs with these features, there turns out to be a distinction between "APIs" like List and "data types" like, say, JsonElement. It's not really useful to pattern match over List but it is immensely useful to pattern match JsonElement. At the same time, the value of extending JsonElement is limited, justifying it as a sealed type.
>
> Also remember that it is already common practice to make types in public APIs final anyway. Extending them might have been useful for some dirty hacks, but it is not in the interests of code stability and compatibility to do so.
>
> It sounds to me more like you have resistance to a particular class being sealed than general issues with the concept of sealed types.


No interface can be declared as final nor has that created any major 
issues before. Again, even JDK code violates interfaces declared within 
itself.


IIRC, FMA is in part depending on this for better performance. Either 
they don't do it and get worse performance or they do it and make higher 
level abstractions less seamless.