Valery ShiskinJetBrains надо делать деньги на продаже IDE. Им нужен позарез промежуточный язык для создания редакторов других языков, особенно, если в проекте допускается использование двух и более языков. Трудно создавать редактор для Scala (что мы и наблюдаем во всех IDE), имея в качестве базового только Java.
Это не мое мнение - это один из первых пунктов в объянении jetBrains "для чего им нужен новый язык".тогда для чего они делают плагин Kotlin для Eclipse?

Пока IDEA им приносит доход они будут развивать ее, как только перестанет - будут продавать другой ПО или услуги. Тот же самый continious integration в облако загонят. На текущий момент у них достаточно профессионалов чтобы делать проекты довольно высокой сложности. Потому Kotlin им нужен для того чтобы самим писать много-много-много продакшен кода. А чтобы язык жил и развивался нужна аудитория.

GKS_SamaraЧем описывать - дело десятое. Всё одно в яве их нет.
Можно и на дату ввести ограничение- например метод, принимающий дату
рождения, может запретить даты больше текущей ;)В java легко реализуется и уже сделан контракт на данные - Bean Validation.

А где есть контракт на вызов функции и насколько это помогает в реальной разработке?

GKS_SamaraДобрый день, VoDA!

Я пытался кое-ка это прикрутить к delphi и java - забавно, но полностью
реализовать невозможно (в частности из-за наследования).Можно сделать на базе Spring через проксирование, а сами контракты прописывать аннотациями или через applicationContext.

Только основной мой вопрос остался не отвеченным - какие действительные проблемные ситуации это решает в продакшен системах? как часто эти проблемные ситуации проявляются?

и собственно сравнить затраты времени на поддержание контрактной системы и на поиск одного-двух багов, которые подпадают под эти контракты.

Есть какие нибудь данные на эту тему?


PS мысль, что если бы контракты реально помогали их запилили бы довольно давно

BlazkowiczИдея такая, что исключение возникает не в том месте где используются невалидные данные, а в том где они только появляются.А что мешает для всех сущностей написать сеттеры проверяющие валидность данных? как только собрали не валидную сущности, так сразу получили эксепшен...

понятно что Runtime-time слабее Compite-time, но даже так можно достигнуть поставленной задачи.

на той же Scala можно вместо базовых типов применять собственные типы, которые содержат ограничения. тогда можно и компилятором проверки делать.

BlazkowiczVoDAСвойства в Kotlin есть, но я не увидел их как First Class Property. потому пока можно пользоваться свойством, но нельзя сослаться на свойство :(Блин :(Есть надежда

В комментариях одного из разработчиков нашел псевдо-код:

Причем планируется и ссылка на конкретное свойство конкретного объекта и экстеншен свойства.

a#b gives you a property object that you can read from/write to, and
A#b give you an extension property object that you can call on instances of A

Для ORM и обычных нужд нужны A#b, т.е. extention properties. Это аналог java.lang.reflect.Method для Kotlin.

BlazkowiczVoDAА что мешает для всех сущностей написать сеттеры проверяющие валидность данных? как только собрали не валидную сущности, так сразу получили эксепшен.
Ничего не мешает. Поэтому никто и не пользуется.значит удобство от такого рода контрактов перекрывается геморроем по поддержанию контрактов, т.е. контракты не выгодны. по крайней мере в текущей их реализации.

Basil A. SidorovПроверка соответствия типов всё равно выполняется, так что определить "это null" - придётся, остаётся как-то выкрутиться, если null пришёл туда, где анонсировано его недопустимость.

P.S. Да, я помню, что исключение должно кидаться тому, кто прислал null в непотребное место, но неужели так много желающих выкинуть весь или почти весь сторонний код?задача в том, чтобы null не мог придти туда, где его не ждут. в Kotlin это реализуется контрактом и статической проверкой.

в том же Kotlin сторонний код можно выполнять, что при совмещении типов придется провести ОДНУ проверку на null. в java проверки на null приходится раскидывать по всему коду. и даже в этом случае периодически подрываешься на NPE когда начинаешь использовать старый функционал чуть по другому.

PS был случай когда часть свойств в Entity завернули в embedded. каково же было мое удивление когда рабочий код в другой подсистеме начал взрываться от NPE. оказалось, что embedded может не инициализироваться если все поля пустые.

Petro123VoDAв том же Kotlin сторонний код можно выполнять, что при совмещении типов придется провести ОДНУ проверку на nullмож я пропустил, как и где там делается?Это принцип

в Kotlin переменные удобно и практично определять как Int, String. Т.е. notnull переменные. Любой возврат из java кода расценивается как Int? и String? т.е. nullable переменные. из одной переменной в другую записать можно только после проверки на null.


PS попробовал на Kotlin писать код. Действительно удобно. А главное зная java на kotlin начинаешь программировать уже минут через 5-7. максимум это понять какие есть ключевые слова типа 'in'.