RFR: JEP 360: Sealed Types (Preview)
Ty Young
youngty1997 at gmail.com
Tue Apr 14 06:39:30 UTC 2020
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.
More information about the amber-dev
mailing list