Комментарии 11
Многое из этого приходит только с опытом написания api для других разработчиков и чтения примеров реализации в либах. Довольно круто, что собрали всё это в одной статье. Никогда не нравилось, когда используют java-like factory-методы там, где можно обойтись красивым синтаксическим сахором, сделав апи прекраснее
Говно этот ваш котлин
А вот оставили бы слово new и не было бы проблем с неоднозначностью. В джаве ведь тоже можно статический метод создать и с большой буквы его назвать, вот только если new нет то не считается.
Ну, вот только что показали неоднозначность из-за того что убрали слово new, а ещё убрали checked exceptions и подозреваю ещё кучу чего полезного сделали через жопу
Да-да, только вот все последние нововведения в Джаве очень похожи на погоню за Котлином.
А вообще, вам бы как-то по-культурнее, что ли, мысли выражать. А то в каждом комменте то "говно", то "жопа".
Я согласен, что есть определенно полезные вещи типа отмены необходимости писать сеттеры/геттеры и, в частности, именно эта фича решалась использованием Lombok еще до появления Котлин.
По поводу погони: много фич и из Котлина и из другого дерьма(типа Скалы, Groovy и т.п.) продиктованы маркетинговыми усилиями, поясню - на одной из конференций СТО JetBrain сообщил, что при создании Котлин руководствовались принципом сделать язык проще, и, в чем-то он наверное прав, в частности, общепринятая причина отсутствия checked exceptions это - "пользователи не умеют их правильно использовать" (но я не согласен, что обрезание функциональности улучшает ЯП),в результате из Java комьюнити оттянулась часть в Колин и, чтобы их удержать/вернуть приходится вводить те же фичи, чего доброго и исключения вырежут.
зы.Ваше пожелание о повышении культуры выражения замечено, я над этим работаю постоянно посильно как могу, отдельная благодарность, что это не помешало вам ответить на мой комментарий
С одной стороны штуки прикольные - особенно контекстный конструктор. Например один и тот же код может по разному вести себя в дебажном и продовом окружении заменяя запросы на моки и выводя логи например.
С другой стороны - один и тот-же код может вести себя по разному в разном окружении! Как можно в чём то вообще быть увереным!
Напоминает ситуацию с пропертями (val/var) - когда это может быть локальная переменная, а может быть вычисляемое значение - и вот уже на первый взгляд одинаковые
item.property.one + item.property.two + item.property.three
и
item.property.let { one + two + three }
на деле совершенно не одинаковые.
Конструкторы-самозванцы в Kotlin