Ну там два смысла. Один в том, что можно наследовать наследника силед класса от кого-то еще. А в по пропозалу дополнительно можно будет не в одном файле все объявлять
Ну такой же, как и у sealed class примерно: точно известен список прямых наследников.
То есть фактически сумм-типы, только кривые, потому что на JVM по другому нельзя
Давайте сначала доку почитаем, потом пропозал, а потом набрасывать
Вот честно, не понимаю, как устройство байт-код стэк машины мешает реализовать ту или иную систему типов на этапе компиляции.
sealed class, но можно ещё от кого-то наследоваться
Библиотеки скомпилированные могут быть. И все ограничения на наследование к ним должны применяться по максимуму при взаимодействии с ними.
Опять же, на что это влияет? У JVM байт кода достаточно средств для выставления на скомпилированном коде самых разнообразных меток для воссоздания того, как это выглядит в таргет языке с точки зрения интерфейса взаимодействия.
А как это будет в джаве выглядеть? Всё-таки котлин позиционируется как язык, у которого интероп в обе стороны работает. Но, конечно, с текущими инлайн-классами он начал съезжать с этой дороги.
Ну часть ограничений просто в джаве не будет работать. Так же, как сейчас нуллабельность в джаве не проверяется.
Ну проверять значения на входе на null заметно проще, чем на соответствие множеству типов
Такова жизнь 🤷♂
Это уже точная информация? Может тогда и классы можно будет в разных файлах объявлять?
ну это мелочь, честно говоря. но вот сами sealed interface - это важная фича
Мелочь, которую я жду уже года 3 :)
Мне банально не нравится объявлять кучу классов в одном файле.
Да, для них там, написано: "Restrictions on placement of subclasses of a sealed class are relaxed to match those of the sealed interface above, which are repeated below for completeness." Вообще кип недлинный, можно целиком прочитать.
Да, почитайте пропозал по ссылке
Обсуждают сегодня