вот эта я сейчас баг в студии поймал

энивей, изначальный тезис был не про это, а про то, что хорошесть разработки библиотек на языке разработчиками языка  сомнительна

Мне ооочень хочется, чтобы у них также не было positional destructuring, с ним мы уже намучались с data class'ами. Жека Вартанский даже блокпост написал на тему "не используйте data class'ы, если хотите развивать своё АПИ". Есть некоторые идеи, как сделать named destructuring, и таким образом просто не предоставлять positional destructuring по умолчанию. Понятно, что если очень нужно, то можно ручками написать component1, component2 и так далее.
Ещё открытый вопрос с наследованием. data class'ы нельзя расширять. Я ещё покопаю в причинах такого решения. Хотелось бы это пофиксить в велью классах, а то дейта классы выглядят убого по сравнению с обычными классами. Хотя понятно, что как замена POJO они хороши, но недостаточно хороши с моей точки зрения - слишком много ограничений.

Эх, сейчас бы POJO наследовать друг от друга в 2к20, 19 лет спустя первого издания  Effective Java

корутинки однознашна

extensible records же

Эх, сейчас бы POJO наследовать друг от друга в 2к20, 19 лет спустя первого издания  Effective Java

корутинки однознашна

Вот оно вроде и грешно, но состояние описывать с наследованием удобно было бы

деструктуризация дата классов действительно проблемная фигня, как только меняется дата класс - все места использования приходится фиксить.  хотя по синтаксису - подобного же удобства можно достичь с блоком with(obj){...}

если состояние это набор фактов, то как бэ.. наследование фактов... дичь какая то, не?😂

Вот оно вроде и грешно, но состояние описывать с наследованием удобно было бы

если состояние это набор фактов, то как бэ.. наследование фактов... дичь какая то, не?😂