если бы это можно было назвать передачей по ссылке, то ты передавал бы именно ссылку, и не мог бы изменить ее значение в методе

Push LObject

то есть это реально не другая постановка определения

объекты по ссылке, примитивы по значению

не прав

не прав

читай дальше

всегда по значению

самое прикольное, обсуждали это недавно и все так же повторяют мантру, про значение и ссылку, хех)

После с++ смущает то, что имея переменную с ссылкой, можно обратиться к методам и полям объекта без гемора типа & и *.

как уже определили, объекты передаются тоже по значению. только по значению не самого объекта, а указателя на объект

А указатель это не ссылка? Не значит ли это, что передаются по ссылке?

А указатель это не ссылка? Не значит ли это, что передаются по ссылке?

не совсем. ссылку ты в итоге поменять не можешь

да, потому что она КОПИРУЕТСЯ

как и примитивное значение

т.е. происходит передача по значению

для примитива - его содержимое, для остальных - ссылка

Спасиб, просто тоже повторял мантру до этого момента

null-safe говорили они, не будет бойлерплейт кода, говорили они

null-safe говорили они, не будет бойлерплейт кода, говорили они

К чему это? Мапа-то со String? объявлена.

на моменте .filterValues { it != null } можно понять, что мапа теперь <Long, String>

хотя конечно очень узнкий юзкейс, а реализовать его на дженериках очень сложно

потому что T? -- уродство

для Option такой проблемы просто нет

Т? -- это прекрасно, а Option -- это костыль, который говорит, что java не осилила поддержку null-safe на уровне языка

все так, только наоборот Т? -- костыль

если бы джава в компайл тайм могла бы запретить запихивать null в переменную Option<T>, я бы согласился, что Option -- это решение

и то

T в Option<T> уже не влезает, например

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

T? очень даже не уродство

это худшее, что есть в котлине

а джава скопилирует Option<T> nullSafeVariable = null; -- это просто курам насмех

тогда ты не понял котлина)

я его очень хорошо понял

спорить не будем)

Т? -- это прекрасно, а Option -- это костыль, который говорит, что java не осилила поддержку null-safe на уровне языка

Optional ввели скорее для обратной совместимости.

зачем мне абстракция над null , которая помогает мне только когда все в команде следуют соглашениям? Для этого уже есть аннотация @Nullable

все просто -- не пиши наллы, и будет тебе счастье а если поле может отсутствовать, то оборачивай в опшн

Optional ввели скорее для обратной совместимости.

я не уверен, мне не кажется можно было ввести поддерку null-safe хоть в каком-то виде на уровне языка и с поддержкой обратной совместимости

T? я называю костылем, потому что это частный случай частного случая монады, который хреново композируется

все просто -- не пиши наллы, и будет тебе счастье а если поле может отсутствовать, то оборачивай в опшн

спасибо, кэп. А что мне делать, когда один из ста программистов решил забить на это? Падать в рантайме?

T? я называю костылем, потому что это частный случай частного случая монады, который хреново композируется

мы тут продакшен код пишем, а не дрочим на ФП из скалы)

бить его по пальцам просто забудьте про наллы это как с ие6 было -- он "жил" только потому, что его юзали программисты

это не фп и не из скалы это азы здравого смысла

здравый смысл весьма индивидуальное понятие)) не стоит навязывать)

вы думаете, из джавы нельзя передать null в аргумент типа Т? ?

а джава скопилирует Option<T> nullSafeVariable = null; -- это просто курам насмех

будет точно тот же

я не уверен, мне не кажется можно было ввести поддерку null-safe хоть в каком-то виде на уровне языка и с поддержкой обратной совместимости

Ну только если указывать String? - как non-nullable. Но это было бы ужасно.

бить его по пальцам просто забудьте про наллы это как с ие6 было -- он "жил" только потому, что его юзали программисты

в смысле бить по пальцам? Можно даже уволить человека, только это не спасет тебя от того, что в продакшене получишь NPE

если из джавы передали налл, тебя Т? не спасет

в смысле бить по пальцам? Можно даже уволить человека, только это не спасет тебя от того, что в продакшене получишь NPE

Открою тебе секрет, ты даже с nullable типами гарантировать этого не можешь. Ибо прилетит тебе с FE что-нибудь с null - и всё.

Ловишь NPE.

проблема в человеческом факторе, кто-то очень тупой, за ним кто-то очень неответственный не проследил, кто-то ленивый не проверил, кто-то незнающий запустил это в продакшен -- и вот бизнес мертв из-за несоблюдения SLA

Открою тебе секрет, ты даже с nullable типами гарантировать этого не можешь. Ибо прилетит тебе с FE что-нибудь с null - и всё.

fe ? передний конец?

fe ? передний конец?

Front-end.

С клиента, если так понятнее.

это проблемы переднего конца

Я позавчера словил NPE в hashCode()

вот такой жести не было бы, буть у джавы поддержка null-safe

её нет, и Т? помогает лишь частично

и хуже, чем опшн

собственно, поэтому и не люблю этот Т?

ладно, фиг с ним с котлином

чем Option<T> лучше чем @Nullable ?

Option(null) ==None

оно ловит наллы при создании

null == null

null ловит null'ы еще раньше

ERROR: S client not available

и не надо класса и объекта отдельного, который null держит

Nullable, в целом, норм, если все его ставят

но твой аргумент -- а если кто-то не поставил, то ты забыл проверить, и нпе

и не надо класса и объекта отдельного, который null держит

оверхеда нет, если что

для Some(x) vs x есть -- один хоп

это где-то наносекунда на 100 вызовов

то есть плюсов у Optional над @Nullable нет ?

Option(null) ==None

вот он

я не понимаю, зачем нужен класс над null-ом

чтобы явно показать, что вот этот аргумент может отсутствовать

и не знаю, что такое Optional(null). Есть Optional.of(null) и Optional.ofNullable(null)

чтобы явно показать, что вот этот аргумент может отсутствовать

но @Nullable тоже явно показывает это

ага, и он тоже лучше Т?

с такой точки зрения, аннотация и обертка равнозначны

тем более class MyClass { Optional<T> param; } -- считается моветоном class MyClass { @Nullable T param; } -- норм

а Т? -- херня

да забей ты на T?

я сейчас только в джавных терминах спорю

Optional vs @Nullable

окей обертку куда проще юзать в стримах

нехилый тут пожарец

Я год пытался приучиться к Optional. В итоге с ним проблем больше, чем от @Nullable

а nullable на уровне иде или джавас работает?

окей обертку куда проще юзать в стримах

тут я согласен. Но там только синтаксический сахар. Я как-то не очень возбуждаюсь от синтаксического сахара

а nullable на уровне иде или джавас работает?

IDE онли

подозреваю, что первое, и это ещё минус

нулабл это же от брэйнсов?

гугл вроде

@NotNull

но ты пойми, Optional тебя не защищает от появления null в неожиданном месте

Станислав, так ты какой вывод сделать хочешь? что Котлин не нужен??

я понимаю аннотация тоже, и вообще ничего не поможет