RFR: JEP 360: Sealed Types (Preview)

[Brian Goetz]

As often happens, this thread has strayed far from its original purpose, and we are now off in a rathole.  Meanwhile, Vicente had a specific goal in starting this thread, which is now lost in the sea of replies-to-misguided-replies.  

So, to get us back on track: Vicente is looking for substantive, actionable, *constructive* comments on the text of the JEP, the specification, or the implementation.  Commentary on why you think the feature is unexciting, complaining about process, disconnected complaints about other projects, straw man arguments about “but what if you sealed List”, etc, do not count.  Let’s get back on track — this is a *development* list.  

Thanks everyone!

> On Apr 14, 2020, at 2:39 AM, Ty Young <youngty1997 at gmail.com> wrote:
> 
> 
> 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.
>