- 1
- 2
if (optional != null && optional.isPresent()) {
...-
Java / Говнокод #18291
+78
Запостил:
zazazazazaza,
07 Июня 2015
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Ну и чё не так с этим кодом, если жаба всё-таки не проверяет второе условие в случае фейла первого?
на C#
1) нулл
2) флажок в объекте
Имхо, надо что-то одно оставить.
Тут ГК на тему "пофантазируйте, каким надо быть уебаном, чтобы в переменную Optional<?> optional поставить null". Например, выше по коду что-то вроде
Optional<?> optional = someShit();
...
@Nullable
private Optional<?> someShit() { ... }
Или такое, например:
Optional<?> optional = rndBoolean() ? null : Optional.empty();
По сути - патерн special case для valueType
как и в null
valueType -> значение -> содержать -> всегда. Всегда.
Ты наверное переутомился, хочешь банан?
Throws:
NoSuchElementException - if there is no value present
Class OptionalInt
а класс не вельютайп ну ни как
>> вельютайп
>> По русски говорить научись, блядина.value type.
Чет я не помню таких русских букв.
>> Примитивный тип?
Еще на хохлятский переведи устоявшийся термин
Можно еще с греческого перевести
Хроника - временица
Ипподром - конебежка
Библия - книга
Хотя у вас такой бред практиковался после оранжевой революции.
>Хотя у вас такой бред практиковался после оранжевой революции.
Откуда ты знаешь, ты тогда не в детсад ходил случайно?
Страшен не ты, Сема, страшно то, что тебя породило
Если чего-то может и не быть, Optional<T> в типе скажет всё без аннотаций и излишней документации. И компилятор заставит тебя делать дополнительный шаг (get()), прежде чем ты обратишься к значению.
При правильном использовании в Optional не будет пустых ссылок. Например, в Optional есть метод-конструктор fromNullable, который автоматом конвертирует null в nothing.
Если ты дереференсишь Optional без проверки - ССЗБ, тебя предупреждали.
Например, у Map есть метод ValueType get(KeyType). Если ключа нет, что будет? Надо читать доку. Пистон в похожей ситуации кидает KeyError (если рассматривать его оператор [] а не метод get()), жаба возвращает null. Если бы сигнатура была Optional<ValueType> get(KeyType), то подобных вопросов не возникло бы. Особенно это приятно при ревью кода. Сразу видно, что может пойти не так, и где автор кода схалтурил на проверках.
В функциональных языках есть удобные функции, позволяющие вместо унылых проверок isPresent() использовать более компактные варианты с map/flatMap, ориентируясь на положительный кейс, но для жабы версии <8, где нет нормальных лямбд, это не аргумент.
Или навести указатель на имя функции?
Так это единственный плюс? "Сразу видно"?
В вебе? Ты в код-ревью хоть раз участвовал?
Когда уже вы, идеёбы, вылезете из своего уютного мирка и поймёте, что код нужно уметь нормально писать и читать без IDE?
А он тоьлко в вебе?
>Когда уже вы, идеёбы, вылезете из своего уютного мирка и поймёте, что код нужно уметь нормально писать и читать без IDE?
Но для этого надо выкинуть жаву нахуй. Что ж ты, жаваеб, тогда делать будешь?
Так участвовал или нет? Какой инструмент ты использовал? Все более-менее вменяемые и популярные инструменты веб-ориентированы. Crucible, GitHub, Gerrit, Differential, ReviewBoard.
> Но для этого надо выкинуть жаву нахуй.
Ты удивишься, но я могу неплохо писать на жабе и не только на жабе без IDE.
>Ты удивишься, но я могу неплохо писать на жабе и не только на жабе без IDE.
Я тоже хелловерд могу сбацать, но без ide жава сосет у динамических языков, а с иде - они сосут на среднекрупных проектах. Своим умением писать на жаве без ide ты в лучшем случае на проезд заработаешь.
А динамические языки сосут хоть с иде хоть без иде. Доказано весёлой отладкой чужого серверного кода на пистоне.
За 5 секунд пишешь проги?
Рабочая ровно до той ветки, в которой опечатка.
А я только что написал в голове операционную систему, компилятор, социальную сеть и 3d игру.
Динамически языки - для мелкой питушни - типа юзерскриптов - навалил и забыл
Еще один. Кто тебе сука сказал что я больше ничего не осилил? Просто падсибя он удобнее языков со статической типизацией. О, да ты сам это и написал.
Я уже всё написал, если непонятно, перечитай ещё раз.
Придумали для того, чтобы снизить вероятность случайно натолкнуться на NPE. Чтобы код, который может ничего не вернуть, декларировал эту возможность явно. Т.к. явное лучше неявного, import this. Проверку на null легко забыть. Проверка содержимого Optional естественна, её необходимость видна без всякого null-анализа.
Optional не может предотвратить обращение к несуществующим элементам, он просто делает вероятность случайной ошибки меньше за счёт введения дополнительного типа-контейнера.
А NPE в жабе стараются избегать, по возможности, не юзая null. Т.е. если возвращаешь массив - просто верни пустой массив. Если значение или null - можешь вернуть optional. и т.п.
Так никто мне не ответил чем лучше optional, кроме того, что не надо лезть в доки без ide.
> Причём сразу известно, какое именно. А не null/undefined/false/0.
Что значит "какое именно"? Там можно задавать своё значение по умолчанию? Вроде бы не я такого видел, если только не наследоваться от этого. Или это про orElse?
> да и забыть не получится, ибо оно в x без get()'а не кастанётся
Подождём появления на ГК отрывков кода, где будут использовать get без проверок.
В общем, из-за orElse и подобных методов фича полезна, а в остальных случаях только усложнит код всякими Optional<pitux> и теми же проверками на null внутри Optional и становится чем-то похожим на принципиально разные undefined и null в жс. Только до двух пустых значений в жс додумались за неделю, а в жабе - за несколько лет.
Ну, бля, а я о чем? Пока что это тот же null вид сбоку. Кстати а зачем в js джва типа null?
Но если null выпилить, будет только лучше.
Вот два куска кода:Где проще разглядеть потенциальную ошибку? Где проще её допустить при первом написании?
В примере, что в первой части, что во второй так же просто/сложно разглядеть/допустить ошибку.
Сначала программисты тренировались писать != null, теперь придётся чуть изменить написание. Но суть не изменилась, разве что IDE стала что-то подсказывать.
Пока всё же складывается 2 лагеря - статическая типизация vs динамика.
Приверженцы динамики не понимают усложения, т.к. они не привыкли, что есть компилятор, который проверяет типы, что можно проектировать код так, что структура программы сама мешает тебе допускать ошибки. А запомнить один универсальный == null проще, чем париться с какими-то дополнительными проверками.
Рекомендую смотреть видео Yaron Minsky, квинтэссенция неплохой книжки Real World Ocaml, полезной даже тем, кто не собирается писать на OcamlСёме разрешается не смотреть - видео на английском.
Мы привыкли, что если вместо объекта типа X поставить Y, то это обнаружится на этапе запуска. Любители статической типизации узнают это на этапе компиляции.
Но тут два механизма позволяют делать одно и то же: хранить либо пустоту, либо значение. В обоих случаях нельзя подставить X вместо Y, в обоих случаях можно положить null вместо значения, оба механизма ведут себя как Maybe.
Пока что мне удалось услышать про намеренный возврат null. То есть это типизация в головах поддерживаемая компилятором? Как говорил Борманд, программисты избегают null, из-за чего у них X - значение, никогда не null (потому, что программист так решил; как константы в питоне), а Optional<X> - значение, иногда null, что проверяется на этапе компиляции.
Optional - дополнительное напоминание. Мне лично нравится, когда код сам напоминает мне об ошибках. До тех пор, пока это не Checked Exceptions.
Если это какая-то то банальность разжеванная 100 раз на русском в письменном виде - действительно, нах?
Например, Шен, язык в котором проверку типов можно включить или выключить во время выполнения програмы. Каким языком его считать? Система типов в Шене примерно такая же по выразительности / количеству инструментов как и в МЛ-подобных языках.
От того, что в Си типы проверяются на этапе компиляции никто не даст никаких гарантий по поводу правильности типов. При желании указатель одного типа можно привести к какому угодно другому типу, и получить ошибку типизации.
Что интересно, при этом, в языках без типов, например в Форте, получить ошибку типизации нет возможности.
В языках логического програмирования, как правило от системы типов в том понимании в котором она присутствует в МЛ-подобных языках нет толку, т.как сами языки как правило могут лучше выразить то, что должна выразить традиционная система типов. И там аргументы "динамический" против "статический" вообще как на корове седло.
Дорогой поциент! Мы все как-бы в курсе что правила того, что во что кастится не имеют никакого отношения ко тому, когда именно эта проверка выполняется: в рантайме или в моменте компиляции/трансляции.
Можете смело возвращаться в свои пинаты, пить опипромол и ложиться спать.
Она так же не может быть статической или динамической. Это просто не применимо к вопросу о качествах системы типов.
А википедия не знает.
Динамическим или статическим может быть ее представление(?) в языке, так?
В конце девятнадцатого - начале двадцатого века математики старались найти формализм обобщающий всю математику. Их было несколько идеологических груп: платонисты, типа Геделя, логики, типа Фреге, Хилберта, Рассела и т.д., идеалисты типа Брувера. Самая привычная картина мира, по крайней мере для обывателя - это платонизм, т.е. ситуация при которой математические идеи существуют в своего рода "параллельной реальности" не зависимо от людей которые о них знают. Для этой же системы мировосприятия очень подходит описание математики базирующееся на теории множеств. Т.е. то, как в современных вузах обычно преподают введение в математику - это как раз наследие платонистов.
У этой системы есть проблемы. Одна из главных проблем это необходимость принятия аксиомы выбора, или, перефразирую, необходимость принятия правила исключенного третьего. Не вдаваясь в подробности, это создает очень много проблем, хотя и позволяет просто решать другие проблемы.
Теория типов - это попытка избежать зависимости от аксиомы выбора в фундаментальном описании математики. Другая такая попытка, например, - лямбда исчисление.
Как это относится к нашей дискуссии: типы и системы типов, это один из основополагающих математических формализмов. Мы можем с уверенностью говорить о том какими свойствами обладают типы / их системы, и какими нет. С точки зрения програмиста, система типов - это инструмент для описания правильности и выразительности програм. То, что обычно подразумевается под "статической" или "динамической" типизацией имеет столько же общего с системой типов, как качество бумаги на которой напечатана книга к содержанию книги.
То есть динамическая система, например, подразумевает доработку на этапе компиляции, а статическая - на лексического анализа.
Я правильно понимаю?
Где, на мой взгляд есть настоящие различия (при том, что типы вообще имеют место быть):
- язык может позволять формально указывать типы: иногда, всегда, никогда.
- язык может гарантировать, что информация касающаяся типов будет присутствовать во время выполненя програмы: вся, частично, никакая.
В зависимости от выбраной системы типов (выразительность и правильность) у языка могут быть другие качества. Например, если выбрана неправильная (unsound) система типов, то у языка появляется плюс в выразительности, но меньше гарантий в отношении правильности (пример: Си, Ява). Пример обратного: Хаскел, Окамл. Для языков, которые стараются сохранить правильность характерно стараться компенсировать потерю выразительности за счет ограниченого принятия дополнительных правил из логики более высокого порядка (полиморфизм, мета-логические предикаты типов).
Интересно, но увы, мне не понятно
http://www.amazon.com/dp/0262162288/?tag=stackoverfl08-20 - нужно читать после какого-нибудь подготовительного материала. Я сдался после нескольких абзацев :)
Можно еще вот это почитать: http://math.boisestate.edu/~holmes/holmes/nf.html - это напрямую не связано с програмированием, но очень даже связано с теорией типов.
Что уж обо мне говорить)
Я как то хотел почитать серьезную книжку о лямбда исчислении, но концентрация непонятных слов на сантиметр текста вынудили меня отказаться от этой идеи. Поэтому познаю сквозь призму ФП
А вот Шерлок Холмс не изучал всякую ненужную фигню и был крайне эффективен. Не засоряйте свой чердак, Ватсон, ненужным хламом.
Это аналогично знанию "в байте может быть не восемь бит". Справедливое утверждение, но вероятность того, что оно потребуется, крайне мала. Обладая этим знанием, человек лишь сможет разочароваться в жизни и писать длинные посты на форумах, о том, какие все тупые и забыли, сколько бит в байте.
Уж лучше пойти в практическое русло: погрузиться в область алгоритмов или изучать доказывающую питушню вроде языка Idris.
Мир - огромен и загадочен. Мне интересно прикасаться к его тайнам.
> интересно прикасаться к его тайнам
Системы типов, придуманные математиками - это тайна мира? Тайна мира? Тайна? Мира? Какого мира?
Это искусственная придуманная ненужная фигня. Паразит, который не может жить без подпитки мозговой энергией жертвы.
Это всё равно, что устанавливать игру за игрой и утверждать, что так познаётся мир, утверждать, что умеешь водить машину, стрелять и прыгать на два метра, утверждать, что видел леса, поля и реки.
Это всё равно, что жрать полиэтиленовый пакет и утверждать, что ты - гурман.
Уж лучше тогда изучать геологию и химию. В отличие от "типов", они связаны с реальным миром.
Самообман. Человек может стать кем угодно. Я сейчас я больше занят религией чем математикой, и преобладает религиозный взгляд. Когда я начну читать книгу, которую мне посоветовали, я переключусь
>>Это искусственная придуманная ненужная фигня
Потому что любая вещь за пределами твоего мира - ненужная тебе нафиг фигня. Окукливание.
И за игрой познается. И в музыке познается. Ничего не бывает просто так. Ты просто привык думать, что знаешь причины и следствия.
Но времени мало. Сорокапятилетний семейный человек не сможет измениться. Вероятность крайне мала.
> Потому что любая вещь за пределами твоего мира - ненужная тебе нафиг фигня. Окукливание.
И это правильно.
> любая вещь за пределами твоего мира
Разные вещи стоят на разном расстоянии. Но некоторые всегда будут за пределами.
1. Биология, химия, медицина, физика - всегда актуальны, всегда в нашем реальном мире. Работают над тем, чтобы помочь и улучшить мир.
2. История, информатика, педагогика - стоят на стыке реального и виртуального миров, из-за чего могут давать сбои. Например, изучение древних времён без соотнесения с действительностью и учёта опыта, преподавание ненужной фигни и написание ненужных факториалов на хаскеле. Но при правильном использовании служат реальному миру.
3. Математика, философия, религия - вне нашего мира. Иногда могут давать удобные модели, которые можно использовать в реальном мире.
> И за игрой познается. И в музыке познается.
Ладно, договорились, они не бесполезны. Они вспомогательны дают аналогическую ступеньку, по которой можно подняться, изучая реальные объекты.
> Ты просто привык думать, что знаешь причины и следствия.
Не привык, я же не тот мужик из матрицы.
Но времени мало. Сорокапятилетний семейный человек не сможет измениться. Вероятность крайне мала.
> Потому что любая вещь за пределами твоего мира - ненужная тебе нафиг фигня. Окукливание.
И это правильно.
> любая вещь за пределами твоего мира
Разные вещи стоят на разном расстоянии. Но некоторые всегда будут за пределами.
1. Биология, химия, медицина, физика - всегда актуальны, всегда в нашем реальном мире. Работают над тем, чтобы помочь и улучшить мир.
2. История, информатика, педагогика - стоят на стыке реального и виртуального миров, из-за чего могут давать сбои. Например, изучение древних времён без соотнесения с действительностью и учёта опыта, преподавание ненужной фигни и написание ненужных факториалов на хаскеле. Но при правильном использовании служат реальному миру.
3. Математика, философия, религия - вне нашего мира. Иногда могут давать удобные модели, которые можно использовать в реальном мире.
> И за игрой познается. И в музыке познается.
Ладно, договорились, они не бесполезны. Они вспомогательны дают аналогическую ступеньку, по которой можно подняться, изучая реальные объекты.
> Ты просто привык думать, что знаешь причины и следствия.
Не привык, я же не тот мужик из матрицы.
Я только что прикоснулся к твоей тайне.
Скорее, мотивация не та, слишком сильная потеря комфорта.
Стоит только захотеть. Но захотеть сложно. Проще думать что ты не можешь. Мир тебя наебывает
>>И это правильно.
В твоем мире - да. Но это даже не жизнь
13 Входите тесными вратами, потому что широки врата и пространен путь, ведущие в погибель, и многие идут ими;
14 потому что тесны врата и узок путь, ведущие в жизнь, и немногие находят их.
Ты не ищешь - ты идешь где идется
>> Работают над тем, чтобы помочь и улучшить мир.
Над этим, но не по этому. Работают - потому что нравится
Ты видишь мир из одной точки и тебе так удобнее. Для тебя все - во имя пользы и выгоды. Но в мире нет пользы и выгоды. Это все придумал человек. Миру параллельно на суждения. И человек волен делать все, что угодно
>> Не привык, я же не тот мужик из матрицы.
Не поверишь, но твой мир очень на нее похож.
ибо истинно говорю вам, что многие пророки и праведники желали видеть, что вы видите, и не видели, и слышать, что вы слышите, и не слышали.
Ты не хочешь ни видеть ни слышать
Старость, сэр. Не надо думать, что в любой момент жизни можно захотеть, измениться и совершить чудо.
> Ты не ищешь - ты идешь где идется
Итеративный подход. Там, где идётся - и есть дорога. Легче идётся - твоя дорога. Повернул и стало сложнее? Это чужая дорога, поверни в обратную сторону.
> Для тебя все - во имя пользы и выгоды.
Не всё, не всегда.
> Ты не хочешь ни видеть ни слышать
Пойду почитаю надписи на заборах и посты пи_дара. Может, мне откроется высшее знание. Может, я начну думать по-новому!
Фильтрация крайне важна, иначе потоки данных и наши решения будут подобны белому шуму. Это единственная наша задача здесь - создавать и поддерживать порядок, а значит фокусироваться на своей цели и следовать её, не размазываясь, не тратя себя на генерацию белого шума.
>> Не надо думать
Вот ты и не думаешь. Надо - не надо - установки. Установки разрушают волю
>> Итеративный подход. Там, где идётся - и есть дорога. Легче идётся - твоя дорога. Повернул и стало сложнее? Это чужая дорога, поверни в обратную сторону.
Ты отнимаешь у себя выбор. Впрочем это тоже выбор
>> Это единственная наша задача здесь - создавать и поддерживать порядок
И кому нужен твой порядок?
Человек придумывает свои задачи САМ. Почему ты решил, что твоя задача поддержания порядка нужна еще хоть кому то кроме тебя?
Ты всегда будешь находить то, что ищешь. Ты ищешь подтверждение собственной правоты. Попробуй наоборот
Думаю
> Ты отнимаешь у себя выбор. Впрочем это тоже выбор
Идти по своему пути - лучше, чем бросаться в крайности. Зачем мне метаться, распыляться на мелочи и стараться найти неоптимальный путь? Призрачное счастье в будущем? Зачем мне готовиться к будущему, которого не настанет и выбирать чужой путь, когда можно всю жизнь идти по своему?
> Почему ты решил, что твоя задача поддержания порядка нужна еще хоть кому то кроме тебя?
Потому. Либо порядок, либо смерть. Даже если убить всех человеков, это правило останется.
> Ты ищешь подтверждение собственной правоты. Попробуй наоборот
Интересный ход, симметричный.
Наоборот я пробую, но мне это часто мешает. Всё начинает казаться чистой правдой, так можно и с ума сойти.
1024-- в http://govnokod.ru/18291#comment289628 написал:
>> Не надо думать, что в любой момент жизни можно захотеть, измениться и совершить чудо.
Так зачем думаешь, если не надо?
>> Идти по своему пути - лучше, чем бросаться в крайности. Зачем мне метаться, распыляться на мелочи и стараться найти неоптимальный путь? Призрачное счастье в будущем? Зачем мне готовиться к будущему, которого не настанет и выбирать чужой путь, когда можно всю жизнь идти по своему?
Тут уже - как хочешь. Но ты рискуешь в один день понять, что упустил что то важное. Делать нужно все, что нравится делать.
Будущее - иллюзия. Как говорил Воланд - человек смертен внезапно. Все что у тебя есть - это сейчас. Поэтому если тебе что о хочется - то для этого есть только один момент - сейчас.
>> Либо порядок, либо смерть.
И в этом твой мир
Но не живу в нем. А значит можешь и ты. Но ты не веришь, что можешь, и думаешь, что все такие же)
>> Всё начинает казаться чистой правдой, так можно и с ума сойти.
Так и есть. А когда ты остановишь мир - поймешь что нет ни правды - ни лжи, ни добра - ни зла
Молоток - не философский камень. Молоток не может превратить хрень в золото, но молоток продолжает забивать гвозди. Так зачем забивает, если не надо?
> Делать нужно все, что нравится делать.
Вот и делаю.
> Но не живу в нем. А значит можешь и ты. Но ты не веришь, что можешь, и думаешь, что все такие же)
> А когда ты остановишь мир - поймешь что нет ни правды - ни лжи, ни добра - ни зла
Сойти с ума ради нейтральной пустоты или жить и радоваться? Нет, я уж лучше поживу и порадуюсь.
Незачем) Я не понимаю. Ты делать то, что не должен по своему же мнению? Почему? Забей.
>> Сойти с ума ради нейтральной пустоты или жить и радоваться? Нет, я уж лучше поживу и порадуюсь.
Пустота в твоем мире. Всем нет ничего, кроме тебя самого. Все остальное - отражения тебя. За пределами кокона настоящий мир. Не интересно?
> Не интересно?
Не интересно. Чтобы прорваться во внешний мир (если он есть), придётся найти уязвимость и сломать этот. Работает - не трогать.
В остальных-то ситуациях смысл есть!
Приходит wvxvw на вокзал, и просит билет до Крыжополя.
Кассирша: Вам на южный вокзал или северный?
wvxvw: север и юг -- выдумки маркетологов. Когда я стою на южном полюсе где юг и где север?
кассирша: Вам на вечер или на утро?
wvxvw: вечер и утро -- выдумки маркетологов. Когда я пересек горизонт событий и падаю в сраную сингулярность, то нет не только утра и вечера, времени даже нету.
И тут приходят санитары, и забирают wvxvw обратно в дурку, а за ним бегут чумазые 2014 и kegdan и кричат: "дяяяденька, а что это вы там про сингулярность говорили? Вы наверное такой умный! Самый умный тут! Расскажите нам, пожалкйста"!
Но санитары уже вкатили wvxvw галлопередолу и слюни текут.
Тьфу.
Я не в курсе как проще жаваёбам, то на чем я обычно пишу не кидает исключений если пытаться напечатать null. Может жаваёбы к наллам привыкли. И там и там надо проверять на отсутствие значения.
>он просто делает вероятность случайной ошибки меньше за счёт введения дополнительного типа-контейнера.
Потому что код ревью проводится в вебе?
Смотри: один из смыслов статической типизации в том, что ты кое-что знаешь о возвращаемом типе. Например если вертаемый тип int, то это значение от INT_MIN до INT_MAX. Соответственно можно спокойно пихать его в функцию, ожидающую int без боязни что функция ожидает указатель на строку и поедет по пезде. Компилятор решает эти проблемы за тебя, чувак! Халява!
Из этой строгого, статического рая джав и сишарпов вываливалась ситуация с объектами. Когда речь идет о примитивах (в джаве) или валуе-тайпах (си шарпе) все прекрасно, но когда речь идет об объекте, то тебе могут вернуть не только указатель на объект но еще указатель на хуй (по научному -- null). Значит, уже нельзя спокойно сунуть его в любой метод без боязни получить по влажным губам толстым NPE (или NRE в терминологии острых сей). Проверить это на уровне компилятора никак нельзя, потому что авторы языка пидарасы нулл -- валидное значение для указателя.
В идеальном мире пони срут радугами, и программист *каждую* функцию документирует на предмет возвращения нула, и пользователь функции понимает кто может нулл вернуть, а кто нет. И если кто-то может, то он проверяет на нул и делает какие-то логичные действия вместо получения постыдного NPE.
В действительности же никто никогда не пишет никаких доков, и все как дебилы каждый результат проверяют на нул, засирая код ненужными проверками, а стоит только забыть как ты получишь NPE.
ПРОДОЛЖЕИЕ СЛЕДУЕТ
Кто-то решает проблему аннотациями для статического анализа (Nullable/NotNull), кто-то решает это на уровне компилятора вводя реальные обертки, этакие Maybe: Nullable, Optional итд.
Когда функция вертает Optional, она как-бы говорит "эй, я могу вернуть нул, проверь меня!!" и программист вынужден явно проверить значение. Он не может уже тупо передать его дальше по цепочке, или нарушить закон деметры дернув у него метод и получить отсосный, мининглесс, тупой и бесполезный NPE.
Программист -- тупая, ленивая сука, надо заставлять его проверять ошибки, отсюда и Optional, и Checked Excpetions (которыми ни один человек в мире пользоваться не умеет) да и вся статическая типизация современности в целом
В идеале эта штука должна быть оформлена на уровне языка, а не на уровне сторонней приблуды.
Не понял. Ты хочешь чтобы без аннотаций не конпелировалось?
>В идеале эта штука должна быть оформлена на уровне языка
Ну это в жаве исторически все оформляется в виде сторонней приблуды. Там даже сложение строк в компилятор встроено.
посмотри как сделано в котлине, например. Там нельзя тупо скастить ненулабл тип в нулабл
вопрос: что возвращать когда нету юзера с таким id? Какого-то специального DefaultUser? И так на каждый случай? Не много ли букв писать?
Паттерн *Null object* (именно так правильно называется то, что ты предложил) имеет смысл только в одном случае: когда мы хотим скрыть от клиента что такого пользователя нет, и подставить реализацию которая выполняет контракт и ничего не делает. Например _EmptyUser_, который по методу getName() будет возвращать пустую строку, по методу sendEmail() ничего не делать итд.
Тогда клиент может и не знать что этот пользователь чем-то отличается от особенного.
С другой стороны если он вдруг захочет это узнать, то будет проверять instanceof (или is) и будет еще хуже.
Ну можно делать, как в go. Возвращать заодно ошибку. Тогда правда придется проверять ошибку :) Кода столько же примерно, зато семантически выглядит целесообразно.
Другой вопрос, а не стоит ли тогда проверять сначала, есть ли такой id отдельным способом? И, если есть, тогда брать юзера.
2) нельзя проверять сначала, иначе придется задирать уровень транзакции (если речь идет о БД) или налетать на рейс кондишены: пока проверял он был, а как получил так не стало.
Можно еще checked exception кидать, но на свете нет ни одного человека которому бы это нравилось.
-
делать это атомарно? Понятно, что это требует поддержки фреймворком/языком, но в данном случае во главу угла ставится читаемость и т.д.
И кстати точно так же можно попасть на ситуацию, когда, пока получали, он был, но, пока начали с ним работать, ему лапти настали. С этой точки зрения проверки на null придется разбрасывать везде, где работаем с объектом, разве нет?
2) в базе может лапти и настали, а в памяти у нас он уже есть, и если загрузка там не ленивая то можно и поработать.
Да ну. Просто эксепты сравнительно медленные, а так это как раз правильный вариант.
скорость работы эксепшенов это будет последний боттлнек в твоей системе, сразу же за фрагментированным HDD:)
Джависты просто не понимают их смысла, потому что нигде нет нормального туториала, и у людей в башке каша: они не понимают что чекд эксепшены это часть контракта, а рантайм -- признак этого контракта нарушения
а вот NPE, IllegalArgument и IllegalState -- таки да
а причин бывает несколько
1) контракт нарушен и в памяти теперь хуйпоймичо
2) память кончилась
итд
ну сервера приложений могут конечно это поймать и не дать умереть, но задачу они точно должны завалить
О, иксперты набижали.
Ты путаешь RuntimeException и Error, гений.
Рантайм ексепшен это нарушение контракта. После этого система остается в непонятно состоянии и совершенно не очевидно что делать дальше. В идеальном варианте надо закрыться и умереть. А чекд эксепшен это часть контракта и из него можно восстановиться, но бабуины вроде тебя этого не знают и засрали пол Инета криками о том что "иксепшены это плохо", ага
Да, так должно было быть по задумке авторов жабы. На деле чекед-эксепшены настолько громоздки и неудобны, что 146% авторов библиотек не связываются с ними.
Даже авторы JDK косячат, не следуя придуманным ими же гайдлайнам.
Это явный признак того, что гайдлайны, выглядящие хорошо в теории, на практике могут быть полным говном.
Эксепшены -- отличная в теории конструкция, но никто их не осилил к сожалению. Может быть потому что они правда малоудобны, а может потому что таки да -- нет туториала и никто не понимает когда какой эксепшен кидать и когда его ловить.
это еррор
непонятно правда чому assert это error
Мы любим делать два запроса в базу вместо одного, не правда ли?
Ну и ладно юзеры, их обычно не удаляют, но есть ведь объекты, которые могут быть удалены в промежутке между двумя запросами.
null или кидать эксепт.
>Паттерн *Null object* (именно так правильно называется то, что ты предложил) имеет смысл только в одном случае: когда мы хотим скрыть от клиента что такого пользователя нет, и подставить реализацию которая выполняет контракт и ничего не делает. Например _EmptyUser_, который по методу getName() будет возвращать пустую строку, по методу sendEmail() ничего не делать итд.
Тогда получим пых, который *как-то* фурычит всегда.
В общем-то я тоже могу. Но писать на жабе без IDE не особо приятно. Приходится юзать читы типа import java.util.*; и т.п. С чтением всё-таки полегче.
А если тебе приходится скакать по вызовам (и, не дай бог, ещё какие-то вычисления в уме проводить) - код хуёвый.
Печально, но в жабе на все эти вопросы очень легко ответить.
P.S. Доку к классу не завезли, да.
Положительно?
Само собой. Посмотреть, какого типа context. Это будет или интерфейс или класс. Дальше всё тупо. А в ide даже смотреть не надо будет, само подскажет.
в нехуево написанной программе даже без помощи IDE примерно понятно о чем речь (всякие венгерские нотации и иже с ними в помощь). Как-то же писали люди программы в середине 90х, без всякого код инсайта, и неплохо писали
Сравнил хуй с пальцем. Тогда программы были проще и падали от нехуй делать без внятного сообщения об ошибке.
Doom, OS/2 и Lexicon конечно были проще того сраного интернето-магазинчика который пилит сейчас сраный школоло, обвешанный IDE.
Лексер пишется посредством обычного автомата , он даже в обычном editPlus есть. А вот парсер требует памяти, восстановления от ошибок и прочих радостей которых тогда не было в IDE.
Видно так же что ты школота пубертатная, и в 90е ты сидел не за компьютером, а в папиных яйцах.
Нагугли себе досбокс и BorlandC 3.0, напиши там хотя бы тетрис, а потом скажи мне: сильно-ли тебе подсказывали методы объекта, или тип переменной, например.
у тебя не было детства, чувак!!
Так про что ты спрашивал? Про лексеры и парсеры?
Лексер работает с т.н. регулярной грамматикой или грамматикой третьего уровня в иерархии Хомски (да-да, когда ты пишешь регулярное выражение ты по сути создаешь лексер).
Для релизации лексера достаточно конечного автомата (вспоминаем что регексы это есть конечные автоматы -- НКА или ДКА), то есть хуйни которая просто переходит из одного состояния в другое, память ей не нужна.
Лексер разбивает текст на лексемы (каждая лексема соответствует токену). Например у тебя есть текст на пистоне: "if petuh: print kukarekoo ". Автомат крутится до тех пор, пока не встретит первый пробел и понимает что он вычленил токен "if". Потом он крутится пока не вычленит питуха, и тогда он поймет что лексема petuh это токен VARIABLE. И так он разбирает весь документ представляя его в ввиде пачки токенов.
Он не понимает что тело функции находится внутри функции, а внутри этого тела есть еще цикл итд. Он не имеет стека чтобы понимать что он внутри функции, и потому токены у него выложены не в дерево, а тупо рядком.
Он работает быстро, пишется легко, может подсветить ключевые слова (if например) но явно не может построить дерево программы.
ПРДЛЖЕНИЕ СЛЕДУЕТ
А вот парсер работает с контекстно-свободными грамматиками (второй уровень Хомски) и ему уже нужна целая машина Тюринга с памтью чтобы работать. Его уже ригуляркой не напишешь (нужен BNF или рукопись или flex, yacc, вот это всё) и он уже строит дерево программы потому что когда он входит в функцию он кладет себе в стек об этом заметку.
Парсер уже значительно умнее: например с его помощью можно понимать область видимости пеерменной, делать красивую отбичвочку в программах, писать компиляторы в конце концов.
Обычно все работает так:
Текст -> Лексер -> Парсер -> IDE/компилятор/итд
Так вот лексеры есть даже в Editplus, их даже ты можешь на регулярках написать, а парсеры есть только у компиляторов и серьезных IDE.
И к сожалению в моем борландсишном децтве с синим экраном парсера у IDE не было, и мне некуда было нажать чтобы посмотреть список всех доступных в этой области переменных...
>> да-да, когда ты пишешь регулярное выражение ты по сути создаешь лексер
щито? Ты обкурился?
>> (второй уровень Хомски)
Щито? Я так понимаю ты имел ввиду 2 тип в классификации формальных грамматик по Хомскому?
Парсер - проверяет, что они стоят в нормальном порядке (Зачастую параллельно строит промежуточное представление, например семантическое дерево)
Семантический анализ - проверяет, что вся эта хуйня что то да значит, оптимизирует (инлайны, распространение констант, раскрутка циклов, константные вычисление и все такое)
А потом - зависит от цели. Обычно трансляция в нативный код
Кстати, почему многие пишут, что есть четыре класса грамматик и ссылаются на работу Хомского "Three models for the description of language"? Вот на неё: http://www.chomsky.info/articles/195609--.pdf
Как из трёх стало четыре, откуда взялись их названия?
0 - неограниченные
1 - контекстно-зависимые
2 - контекстно-свободные
3 - регулярные
Ситуация такая: ту статью, да и тему в общем, почти никто не способен понять. Кто-то ссылается на статью, поскольку всё из неё вылилось, кто-то - потому, что не понимает. Хотя, может быть, про 4 типа написали много позже и сослались на статью про 3 типа.
Я эту статью скорее всего не пойму, поэтому и не могу разобраться в том, что происходит.
Я специально не изучал это, у нас год были лекции на тему
0,1,2,3
нуачо
Парсер может работать с любой из грамматик в зависимости от извращенности ваших желаний
>> и ему уже нужна целая машина Тюринга с памтью чтобы работать.
Машина Тьюринга - абстракция исполнителя. Если ты о том, что нужен исполнитель - так он любой программе нужен. и лексеру в том числе.
>> Его уже ригуляркой не напишешь
А ты лексер хотел регуляркой писать? Удачи
>> нужен BNF или рукопись или flex, yacc, вот это всё
Лихо ты компиляторы компиляторов в один ряд засунул с БНФ и какой-то загадочной рукописью
Компиляторы компиляторов (с которыми я работал) создают и лексер и парсер и еще много приятных фич
>> и он уже строит дерево программы потому что когда он входит в функцию он кладет себе в стек об этом заметку.
Щито? Что по твоему "входить в функцию"? В моих терминах - это погружаться внутрь функции из кода. Ничего такого лексер не делает.
>> Парсер уже значительно умнее
тебя?
>> например с его помощью можно понимать область видимости пеерменной,
Нельзя, это делается на этапе семантического анализа. Парсер говорит правильно ли у тебя лексемы стоят, а не что они означают
>> делать красивую отбичвочку в программах
Хз, что ты имеешь в виду
>> писать компиляторы в конце концов
Умиляюсь над твоей способностью объединять совершенно разные вещи
>> Текст -> Лексер -> Парсер -> IDE/компилятор/итд
Артефакт -> Обработчик -> Обработчик -> Средство разработки/ Компилятор (который содержит 2 обработчика)/ итд (видимо прочие псевдонаучные вещи)
Вот что означает эта диаграмма?
То есть, машина тьюринга == конечный автомат?
Конечный автомат - математическая модель того, как преобразовать один набор символов в другой. Представляют его в виде пятерки значений (алфавит, допустимые состояния, начальный символ, допустимые итоговые состояния, правила перехода)
Так что - не равны
А что, токены поместятся в регулярку. Скажем, лексер основать на
А парсер - на
>> например с его помощью можно понимать область видимости пеерменной,
> Нельзя, это делается на этапе семантического анализа. Парсер говорит правильно ли у тебя лексемы стоят, а не что они означают
Область видимости - место в иерархии. Распарсив код КС-питушнёй, мы можем получить место идентификатора в иерархии и можем понимать область видимости.
Говоря сухим, но почему-то уважаемым тут языком, парсер - необходимое условие.
>> делать красивую отбичвочку в программах
> Хз, что ты имеешь в виду
Он говорит о красивом форматировании. Парсинг ведётся с точностью до пробельных символов, стили оформления кода действуют с точностью до пробелов.
Парсинг -> AST -> отформатированный текст
Вот наглядный пример:
> Вот что означает эта диаграмма?
Но диаграмма гостя была и так понятна.
Зачем троллить, если можно прочитать и понять? Секта wvxvw?
А теперь составь регулярку для выделения лексем языка JavaScript
>> и можем понимать область видимости.
Мы - можем. Но не компьютер. На этапе парсера он не знает че кого.
>> Говоря сухим, но почему-то уважаемым тут языком, парсер - необходимое условие.
А еще наличие текста программы, среды исполнения и электричества. Так сюда что угодно можно приписать. Скоп переменной - понятие семантическое, хоть тресни
>> Но диаграмма гостя была и так понятна.
Понятна, исходя из предположения, что автор долбоеб и понятия не имеет о чем пишет. Мне же интересно было услышать объяснение каждой связи
И что, не выйдет? Они ВНЕЗАПНО не влезают в регулярную грамматику?
Выйдет, конечно. Только чуть подлиннее, поэтому я не буду её писать.
> На этапе парсера он не знает че кого.
> А еще наличие текста программы, среды исполнения и электричества. Так сюда что угодно можно приписать. Скоп переменной - понятие семантическое, хоть тресни
> автор долбоеб и понятия не имеет о чем пишет
Понятно, wvxvw укусил. Продолжайте троллить вместе, но гость прав.
Это как хтмл парсить регулярками
>> Продолжайте троллить вместе, но гость прав.
Я не троллю. В чем гость прав? Сформулируй тезис
Нет, заебал. Для парсинга html нужна память, для выделения лексем достаточно конечного автомата.Го на форум.
Нет. Мы же говорим о разбивке на лексемы, да?
А уж лексемы специально сделали простыми. Лексемы вполне можно распарсить регулярками. Их специально сделали простыми, чтобы дать на вход нормальному парсеру КС-грамматики что-то более разумное, чем поток символов.
> В чем гость прав? Сформулируй тезис
Во многом... Гость говорит о том, как оно в нашей жизни. Если не разбирать его текст на предложения и осознавать как единое целое, получается достаточно правдоподобный текст.
Человек просто не углублялся в теорию (спасибо ему за это). С практической точки зрения - идеально.
ты же до операции девочкой был
>оторый пилит сейчас сраный школоло
Вся сложность зарыта в фреймверке/библиотеках. Так что может быть что да.
Как я понял, это для LINQ-подобной питушни сделали:
Теперь можно писать однострочники вместо тернарных операторов и if/else.
На самом деле Optional в Java 8 был введён исключительно для поддержки коллекций.
http://habrahabr.ru/post/225641/#comment_7670597
Фиг его знает, это надо изучать.
и правда
map, filter и orElse и подобное делают эти проверки внутри. Optional делает из типа что-то похожее на коллекцию.
Читайте книжки по хачкелю, там всё это расжёвано.
Но вот только в хаскеле Maybe действительно требуется, а здесь null и так есть.
Вот за этим и нужен ваш опционал хренов - это обвертка которая в себе флаг держит и вельютайп (типа инта). флаг говорит - а стоит ли вообще читать из инта.
Есть блокирующая очередь, и ты хочешь реализовать операцию tryPop(), которая вернёт тебе объект, если очередь не пустая, но не будет дожидаться, пока в очереди что-нибудь появится.
Ты можешь возвращать из tryPop() null и предложить коду самому разбираться, послали ли ему null или просто очередь пуста. Или возвращать Optional<Integer>, который не empty только если в очереди что-то было. Тогда никаких сомнений уже быть не может.
1) ты точно знаешь что такое флажолет?
2) ты хотел сказать осколок?
На 2.37 звучит.
>>ты хотел сказать осколок?
И кстати ты на свой вопрос сам и ответил http://govnokod.ru/18291#comment289296
в питоне даже понятия-то такого нет -- "null".
Там есть None.
Сразу видно что ты и пистона-то в глазы не видал
Ты умеешь отличать вопросы от утверждений? Где я задавал вопросы?
Читается вопрос "что делать?".
Лол. Ну, попробуй почитать рационал гуглеров.Хотя, врядли тебе это поможет - все их аргументы уже приводились в треде.
Ну ты и лалка. Мне лично абсолютно наплевать, поймёшь ты в итоге, для чего нужен Optional<T>, или нет. Я знаю, что Optional в большинстве случаев наглядней и безопасней, чем null. В кодовых базах, которые живут годами, и над которыми работают десятки-сотни инженеров, каждая ошибка стоит дорого, а любой способ уменьшить кол-во ошибок - безусловное благо.
Тебе в твоём пистончике с уютненькой ide в скрипте, который ты написал в голове по пути из туалета, optional всё равно без особной надобности - без нормального компилятора и статической типизации от optional мало толку.
Ну и знай дальше тихо, чего ты тут об этом бубнишь, если внятно объяснить не можешь? Или ты кого-то опытом в интернете на полуанонимном сайте задавить решил? :)
>Тебе в твоём пистончике
Мы же жаву обсуждаем, причем тут питон?
Хуля ты пиздишь то а?
Ну и каким-же это образом во время учёбы в кулинарном техникуме у тебя были проекты, связанные с программированием?