Мы говорили про исключительные ситуации, когда ленивый разработчик просто кидает исключение. А не про про случаи, когда наличие и отсутствие объекта нам одинаково интересно и ожидаемо.
start предполагает начало какого-то процесса. Тут же сессия уже может уже быть, может ещё не быть — в контракте это никак не ограничено. Present Simple — она просто есть, как безвременная абстракция.
Почему же пустые? У неё есть время старта, id узла и прочая нужная информация. А ещё есть админка, позволяющая смотреть список активных сессий и килять неугодных.
Такой контракт ничего не говорит о возможности или невозможности писать в СУБД. Ок, вот вам простой пример. Вам нужно получить сессию, вы пишете что-нибудь типа SessionManager.get(). Если сессия автоматически создаётся заранее, то вам будет просто возвращён её объект. Если же SessionManager решили сделать ленивым, то метод get будет создавать сессию под капотом в момент первого обращения. В какой момент будет запись в бд — спрятано за абстракцией SessionManager. Это не ваше дело в какой момент ему ходить в свою же базу.
Я не нахожу эквивалентные ветки условий, операций и тп. Возможно потому что не понимаю эльфийский, а возможно потому, что алгоритмы-то разные. Поэтому и "кажется", а не "знаю".
Ну и ССЗБ.
При чём тут ML, если мы говорили про C++?
Сомневаюсь.
Там ещё есть ключевое слово shared для контроля конкуретного доступа и immutable сами понимаете для чего.
Как минимум, адекватная реализация шаблонов, исполнения времени компиляции и вот этого всего.
По устарелости дизайна. По тому как современные достижения компьютерной науки вписываются в дизайн языка. По количеству WTF.
А в каком разделе математики есть изменяемое состояние?
Вы вот зря иронизируете. Или вы протухание определеяете по популярности?
Существует полно современных компилируемых языков. D, Rust, Nim.
А вот тут был бы как раз кстати механизм "постов-ответов". Подписался на пост и тебе приходят уведомления о появлении новых ответов на него.
Мы говорили про исключительные ситуации, когда ленивый разработчик просто кидает исключение. А не про про случаи, когда наличие и отсутствие объекта нам одинаково интересно и ожидаемо.
Давайте не вспоминать протухшие языки, а то они так и не помрут.
В том и суть, что "можете", а не "должны", а ещё лучше "оно как-то само".
start предполагает начало какого-то процесса. Тут же сессия уже может уже быть, может ещё не быть — в контракте это никак не ограничено. Present Simple — она просто есть, как безвременная абстракция.
Почему же пустые? У неё есть время старта, id узла и прочая нужная информация. А ещё есть админка, позволяющая смотреть список активных сессий и килять неугодных.
У эксепшена тем не менее будет стектрейс, позволяющий понять откуда он взялся. А у блуждающего по программе None — нет.
Не знаю, да и не важно.
Ну а выразительность дженериков вещь системная, она нужна не только и не столько для checked exceptions.
Такой контракт ничего не говорит о возможности или невозможности писать в СУБД. Ок, вот вам простой пример. Вам нужно получить сессию, вы пишете что-нибудь типа
SessionManager.get(). Если сессия автоматически создаётся заранее, то вам будет просто возвращён её объект. Если же SessionManager решили сделать ленивым, то методgetбудет создавать сессию под капотом в момент первого обращения. В какой момент будет запись в бд — спрятано за абстракцией SessionManager. Это не ваше дело в какой момент ему ходить в свою же базу.Это всё можно было бы реализовать через дженерики.
Если контракт нарушен — паника и экстренное закрытие матрицы.
С каким "таким" подходом? Что за слова надо отвечать? Так я и не называют метод getItem, если не могу гарантировать его возврат.
Я не нахожу эквивалентные ветки условий, операций и тп. Возможно потому что не понимаю эльфийский, а возможно потому, что алгоритмы-то разные. Поэтому и "кажется", а не "знаю".
Подписал контракт — изволь исполнять. Хочешь сэкономить — подписывай иной контракт. Или вы предлагаете делать не то, на что подписались?
TypeScript, например. Ну и в принципе легко добавляется в любой язык с дженериками.