RFR: JEP 360: Sealed Types (Preview)

[Swaranga Sarma]

I think you are generalizing that all interfaces are APIs. This is not the
case. Some interfaces are just data-type abstractions - examples are
JsonElement and Shape et al. List is an API which should never be a sealed
type.

>Again, even JDK code violates interfaces declared within
itself.
This is a problem even without Sealed types; isn't it. Why is this a point
of contention for sealed types.

Regards
Swaranga


On Mon, Apr 13, 2020 at 11:40 PM 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.
>
>