maytonВ коде всегда есть интерфейсы которые реализовывал кто-то другой.
В использовании мы обычно оптимисты. Мы , когда прототипируем , всегда полагаем что string это строка и
Никаких других состояний быть не может. Мы считали что контракт сильный. И мы - не параноики чтобы каждый раз ставить проверки условия кажущуюся очевидность. Мы - в меру ленивы.

Почему мы полагаем, что String это строка? Только потому, что разработчики Java заявили, что ponter'ов у них нет, а на самом деле, Object / String это тот же поинтер только "вид сбоку"

С атомарными типами, у нас же такой проблемы нет. Хотя, и в атомарных типах может быть null ))) например Double.NaN, чем не аналог null'а ?

maytonЧто даёт optional? Молчаливое напоминание. Напоминание а том что есть варианты. Варианты волучения нашего string.

Это какой-то язык для дебилов получается.
Сделайте программу которой сможет пользоваться даже идиот и только идиот будет пользоваться вашей программой ( C )

Вот я ожидаю, что по контракту метод getInn() вернет строку ровно в 10 символов и только цифры. И так как я в этом уверен, то потом к этим символам буду обращаться напрямую по индексу и ожидать только символы 0..9. И Optional мне никак не поможет защититься от строки в 9 символов, т.е. я все равно получу null pointer exception (или array out of bound) только парой строчек ниже.

Или строгая типизация во всем или это какая-то "обосрались на 20%" (((

maytonget с генерацией нового класса исключений.

getOrElse где мы обязаны указать альтернативу.

orElseGet с указанием функции разрешения опционала.

orElseThrow с указанием функции генерации нашего типа исключения в зависимости от ситуации.


Чем это отличается от обычного и стандартного if ?

Т.е. мы предполагаем, что дебил-программист написать стандартный if - поленится, а написать orElseGet не поленится?

Проблема же не в том, что человеку жаль написать if. Проблема в том, что СОВРЕМЕННЫЕ средства (раньше такая проблема была значительно сглажена), приводят к огромным цепочкам через ".". Например какой нибудь Hibernate.

String streetName = getBillById( billId ).getCustomer().getAddress().getStreet().getShorName();

Совершенно осмысленная конструкция, вероятность которой в современных программах крайне высока.

И обычный "нормальный" программист готов добавить проверку streetName на null, но делить ВСЮ цепочку вызовов на кусочки и проверять каждый шаг - явно не готов.

Почему я говорю, СОВРЕМЕННЫЕ средства. Раньше, когда все классы создавали "ручками", проблема была значительно менее острая.

1) Не было такой глубины вложенности классов. Нормальный человек, в этом случае, просто бы поля адреса кустомера прямо бы в Bill и "вхерачил". Т.к. "ручками" создавать такую клюкву классов, ему было бы лениво
2) В данной конструкции и структуре классов совершенно явно нарушен принцип инкапсуляции. (ну не считать же get/set методы за инкапсуляцию?).

А теперь перепишите вышеприведенную строчку на Optional )))) - это же совершенно ничитабельная помойка получится ((( Я вот с ходу даже переписать не могу ((( т.ч. не понимаю, что в getOrElse() указывать нужно (((

95% NPE с которыми сталкивались в Oracle CC&B
1. Длинные простыни через "." при обращение к полям базы через Hibernate. Какое-то поле в БД не заполнено, получили NPE
2. Аналогичные простыни при работе с DOM XML. Какую-то ноду или элемент в XML пропустили, получили NPE
При этом, проверка на null НА ВХОДЕ функции и НА ВЫХОДЕ ф-ции - обычно присудствует. Но делать проверку по всем простыням "." - это действительно умопомрочительно.

IMHO Вот реально, банальный оператор a->b являющийся синонимом конструкции
( a!=null ) ? a.b : null
в 95 % случаев, был бы совершенно достаточен и реализовать легко. IMHO

mikronДиез2. null совместим по типу с любым reference-типом по определению, и проверка на null полностью лежит на программисте. С другой стороны String и Optional<String> - это два разных, несовместимых типа, поэтому потребуется явное приведение между ними (просто не получится "забыть" проверить на отсутствие значения)


Помоему логично - если обьекта нет то о типе обьекта не может быть речи.
Глупо рассуждать о типе теста в дырке от бублика.
Но это обстрактно. Покажи на примере что ты имееш в виду.
Нет, не логично. Тип типом, значение значением.

1) В СУБД, практически у любого типа может быть значение NULL. Но (в большинстве случаев) информация про тип при этом сохраняется и все операции допустимые для данного типа - остаются валидны.

Попытка выполнить операции над объектом со значением null - какой-то результат, правда не всегда очевидный,

2) В Java, null это указатель в пустоту. Объекта нет. Никакие операции над объектов не допустимы (((

В Java попытка выполнить операцию над объектом со значением null - Null Pointer Exception.

Вот смотрю доку на Optional, и вижу, что он обеспечивает гарантию выполнения только одной операции - equals(....). Как-то совсем ни о чем ((( Все же другие операции над объектом, как нужно было обрамлять if, так и нужно будет и с Optional.
(синтаксис изменился, но суть то осталась та же. Тот же if который нужно кодировать руками)

maytonИнтересно что в c/c++ раньше различали null pointer и wild pointer. Как бы два состояния. Щас наверное зависит от компиллятора.
Да никак.
wild pointer - вещь мне кажется встречающаяся не часто

static (глобальные переменные) и члены класса - всегда по умолчанию инициализируются null'ом. Или в момент старта программы (сегмент данных просто инициализируется нулем) или в дефолтном конструкторе
Pointer'ы в структурах WinAPI - общепризнанный способ из MS документации, изначально заполнять структуру нулями memset'ом.
остаются только локальные переменные ф-ции - но их обычно не много, они долго не живут, программист за ними сам следит

IMHO & AFAIK