Здравствуйте, netch80, Вы писали:

N>Здравствуйте, samius, Вы писали:

S>>Допустим, есть некий сервис, возвращающий Optional<T>. И есть некая обертка, обращающаяся к этому сервису. Возможна ситуация, когда вызывающему коду важно, на каком уровне произошел отказ, получен ли отказ от самого сервиса, или от обертки. Следует ли делать повторные обращения через какое-то время?
S>>Высосал из пальца.

N>Мнэээ... 7 раз обернуть в optional — делать повторную попытку через 7 секунд, так? А потом дойдём до 500 обёрток?
Можно, конечно, сделать полиморфню функцию, которая будет ждать 500 сек, приняв 500-кратную обертку на входе, и даже заставить выводить тип компилятор. Проблема в том, что бы объявить функцию, которая возвращает в качестве результата и 7и кратную обертку и 500 кратную тоже. Можно и ее решить, спрятав n-кратную обертку за полиморфно-рекурсивным типом, как у Окасаки. (Кстати, в реализации полиморфно-рекурсивных структур данных рекурсивный Optional<T> может занять достойное место)

Но я вообще не предлагал прятать количественные характеристики в n-кратных обертках, где maxN определяется во время выполнения. Хоть это и возможно, но не очень удобно по сравнению с обычным представлением чисел.

Я немного о другом. При прохождении через слои системы, каждый слой может добавлять к ответу свою опциональность. По аналогии с исключениями, но с той разницей, что исключительной ситуации не возникло. Для одного слоя семантика Optional может означать временную недоступность, для другого — несоответствие бизнес-правилам. Тогда ответ со вложенными Optional<T> однозначно определяет уровень, на котором произошел отказ. Не утверждаю что это правильный подход и что он лучше, чем то, что можно организовать на исключениях или Either.