1. Интересно, что будет в этом контексте с Optional? Ведь он явно используется для случаев, когда мы не знаем - null или не null... Здесь спасли бы Extension-method'ы, т.е. любой «String?» считался бы «Optional» и у него можно было бы сразу же вызывать соответствующие методы, но в Java их вроде не собираются завозить (Lombok не в счёт, т.к. это отдельный инструмент). 2. И что будет, когда все более или менее попривыкнут и начнут писать null-safety-код - не будет ли рябить в глазах от восклицательных знаков? Даже в JSpecify есть возможность настроить null-restricted по-default'у, а тут как default задать - если у меня команда профессионалов и они не допускают null и постоянные «!» смотрятся тафталогией? 3. Не забываем про var'ы и не обозначенные типы в аргументах лямбд - как будет работать вывод типов? Сможет ли он адекватно во всех случаях выводить правильный тип, понимая, где нужен «!», а где - «?»?.. В общем, титаническая работа предстоит Б.Гёйтсу и Ko...
Хорошо, что оставили неопределенную nullability: в Котлине ее отсутствие сильно раздражает. Во многих случаях строгие описания nullability -- это зло. Фишка в том, что иногда nullability контекстно-зависимый и не вычислим в compile time. Поэтому приходится вставлять мусорные чеки даже там, где заведомо из контескта известно, что null не будет, хотя и потенциально возможен. Особенно при chained-вызовах геттеров.
Не совсем понял зачем нужны "String?", если можно просто приравнять "String?" к "String". Зачем плодить сущности? Как по мне, то проще было ключ компиляции добавить -- "все объекты, поля, переменные и проч. NOTNULL", чтобы не пришлось везде сидеть и вхерачивать этот "!"
@@mini_jug Я тут подумал, что логичнее было бы сделать так. Без ключа всё по старому, а добавив ключ компиляции применяется логика "String" == "String!", а нужно позволить null, то ставь "?". Короче как в Котлине. Так как ключ не обязателен, то обратная совместимость не нарушается. А с ключом тебе естественно придется перелопатить проект, чтобы привести проект в порядок.
@@EdwardNorthwind Так сделали в C#, когда вводили Nullability. Но это ещё хуже! Ты смотришь на чужой код какой-нибудь старой сторонней либы, там написано String и ты не понимаешь, старый это код или новый и может ли там быть null или нет и с какими ключами его нужно компилировать. Если раньше ты знал, что доверять никакому типу нельзя в плане нуллов, то теперь написано, что как бы доверять этому типу можно, но на самом деле всё так же нельзя. В итоге всё равно нужно всё проверять на null - это полный бардак, бессмысленная фича, стало только хуже.
Спасибо. Хорошие видео. Только не забрасывай их выпуск не смотря ни на что😅
классная рубрика) мне нравится)
Выпуск топ!
1. Интересно, что будет в этом контексте с Optional? Ведь он явно используется для случаев, когда мы не знаем - null или не null... Здесь спасли бы Extension-method'ы, т.е. любой «String?» считался бы «Optional» и у него можно было бы сразу же вызывать соответствующие методы, но в Java их вроде не собираются завозить (Lombok не в счёт, т.к. это отдельный инструмент).
2. И что будет, когда все более или менее попривыкнут и начнут писать null-safety-код - не будет ли рябить в глазах от восклицательных знаков? Даже в JSpecify есть возможность настроить null-restricted по-default'у, а тут как default задать - если у меня команда профессионалов и они не допускают null и постоянные «!» смотрятся тафталогией?
3. Не забываем про var'ы и не обозначенные типы в аргументах лямбд - как будет работать вывод типов? Сможет ли он адекватно во всех случаях выводить правильный тип, понимая, где нужен «!», а где - «?»?..
В общем, титаническая работа предстоит Б.Гёйтсу и Ko...
вот бы ещё всё это реально добавили в джаву, а не оставили на уровне превью/инкубатора, как string templates)
Слишком круто, чтобы внедрить это в ближайшие тридцать лет (
Хорошо, что оставили неопределенную nullability: в Котлине ее отсутствие сильно раздражает. Во многих случаях строгие описания nullability -- это зло. Фишка в том, что иногда nullability контекстно-зависимый и не вычислим в compile time. Поэтому приходится вставлять мусорные чеки даже там, где заведомо из контескта известно, что null не будет, хотя и потенциально возможен. Особенно при chained-вызовах геттеров.
Разве это не сахарный синтаксис, взятый из Kotlin? Я считаю, что Optional идеально вписывается, чем тот же `?`. Они же идентичны
Использование optional для борьбы с null это глупость вселенского масштаба.
@@АлександрКотыхов-п1д а поподробнее?)
@@АлександрКотыхов-п1д ну да, проще оставить все как есть)
Ничего не понял, в чем отличие от javax.annotation
Это нестандартные аннотации. Они не часть языка. Кроме того, аннотации гораздо длиннее, чем ! и ?
Очень странная фишка, особенно когда весь код в Optional и в конвейерах. “Optional?” - выглядит смешно.
штрих
Не совсем понял зачем нужны "String?", если можно просто приравнять "String?" к "String". Зачем плодить сущности?
Как по мне, то проще было ключ компиляции добавить -- "все объекты, поля, переменные и проч. NOTNULL", чтобы не пришлось везде сидеть и вхерачивать этот "!"
Если всё автоматом станет String?, то у тебя весь проект станет красным из-за кучи варнингов. Ключ будет. Про это вскользь упомянуто в JEP'е.
@@mini_jug Я тут подумал, что логичнее было бы сделать так. Без ключа всё по старому, а добавив ключ компиляции применяется логика "String" == "String!", а нужно позволить null, то ставь "?". Короче как в Котлине.
Так как ключ не обязателен, то обратная совместимость не нарушается. А с ключом тебе естественно придется перелопатить проект, чтобы привести проект в порядок.
@@EdwardNorthwind Так сделали в C#, когда вводили Nullability. Но это ещё хуже! Ты смотришь на чужой код какой-нибудь старой сторонней либы, там написано String и ты не понимаешь, старый это код или новый и может ли там быть null или нет и с какими ключами его нужно компилировать.
Если раньше ты знал, что доверять никакому типу нельзя в плане нуллов, то теперь написано, что как бы доверять этому типу можно, но на самом деле всё так же нельзя.
В итоге всё равно нужно всё проверять на null - это полный бардак, бессмысленная фича, стало только хуже.
@@elton-j5m для этого, вообще-то, существует документация.