case class Address(street: String) case class User(address: Address) val u = Option(User(null)) u.map(_.address).map(_.street)

Джавист мне может и нул засунуть в конструктор, а подом упаду в рантайме.

А где лучше почитать про оборачивание в опшн при матчинге и как внутри стдлиба такое автооборачивание пресекается ?

ну какбэ это стандартная библиотека, Option используется в куче мест. map также используется очень часто.

в твоем примере опшн причем вообще?

Ну и вообще, какой тогда смысл в map?

какой смысл во всем

все тлен, пиши на го, там нет таких проблем

Some(null) - это конечно днище, то какбэ разрешенная вещь

Намного быстрей работает прям, ага.

да, учитывая отсутствие ветвления, гораздо лучше будет оптимизироваться JIT С2

А в Жаве почему по-другому сделано?

Some(null) это ссзб, не более того, семантика вполне адекватная

А в Жаве почему по-другому сделано?

В жаве много чего по-другому сделано, что потом чинится десятилетиями

Some(null) это ссзб, не более того, семантика вполне адекватная

http://m.podborslova.ru/s/%D1%81%D0%B7%D0%B7%D0%B1

http://m.podborslova.ru/s/%D1%81%D0%B7%D0%B7%D0%B1

fixed

джавайские опшены вообще днище

чего стоит отсутствие вменяемого orElse

Ну флэтмэп то как нужно работает, а мэп нет.

Это, кстати, не так. Some(1).flatMap(_ => null) возвращает null )

Some(1).flatMap(_ => null) вообще не скомпилируется

чойто

а нет, этож null

Так оно так и должно работать. Сам обернёшь в опшн.

я с нулами если есть использоую Option конструктор :D он None при null и Some иначе

ну работают они в целом одинаково

семантика map по идее не подразумевает никаких дополнительных действий при маппинге. Оборачивание нула в опшон - это дополнительное дествие, что противоречит семантике

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

Когда я вчера наткнулся на то, что в джаве Optional.map при резолве лямбды в null возвращает empty, я очень удивился) потом долго думал и решил, что какой-то смысл в этом есть

но неявность смущает, конечно

Джавист мне может и нул засунуть в конструктор, а подом упаду в рантайме.

это проблемы джависта

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

раз уж вы знаете, что вызываете, то и чекайте сами

И главный аргумент def f: Int ⇒ String = _ => null def g: String ⇒ Int = _ => 1 Some(0).map(f).map(g) == Some(0).map(f andThen g) если бы map работал, как предложил @dosofredriver, Option бы банально не был бы функтором

он и быстрее будет

afaik в Option инланиться будут всякие isEmpty / get, так что не уверен

И главный аргумент def f: Int ⇒ String = _ => null def g: String ⇒ Int = _ => 1 Some(0).map(f).map(g) == Some(0).map(f andThen g) если бы map работал, как предложил @dosofredriver, Option бы банально не был бы функтором

убедил!

afaik в Option инланиться будут всякие isEmpty / get, так что не уверен

при чём здесь инлайнится, если там extends AnyVal

ух, когда дело доходит до инлаина, то эт жесть начинается)

при чём здесь инлайнится, если там extends AnyVal

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

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

см. аргумент выше

а про какой инлаининг идет речь

jvm или scalac

jvm или scalac

оба

ну вообще jvm

не скалас ведь байткоды гоняет

но тем не менее скалак умеет делать инлаин в рамках баит кода

избегая виртуальщины

но тем не менее скалак умеет делать инлаин в рамках баит кода

@inline / inline намекают да, потому и "оба", там часть методов @inline

ну если вы заговорили про jvm инлаин, то как его гарантировать)

@inline это вообще не гарантия

Oleg ну почти гарантия

ну если вы заговорили про jvm инлаин, то как его гарантировать)

гарантировать -- никак, думаю но если метод небольшой и "нагретый", то должно быть

Oleg ну почти гарантия

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

см. аргумент выше

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

Oleg если у тебя большой метод с кучей байткода внутри, то по сути он уже заинлаинин)

ну работают они в целом одинаково

Нет. Когда я делаю флэтмап, то гарантии по NULL'LESS висят на мне. Когда я делаю map, этим как-бы сам контейнер занимается. В итоге опшн, который, якобы, даёт какой никакой null safety нифига не даёт в случае с map.

я вообще не знаю языка с подобными метками, где можно было бы гарантировать инлайн, даже в С++ нет

смотря о каком инлаине идет речь, повторюсь)

100% это конечно не возможно

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

ок, занесено в мою книгу личных мнений

И главный аргумент def f: Int ⇒ String = _ => null def g: String ⇒ Int = _ => 1 Some(0).map(f).map(g) == Some(0).map(f andThen g) если бы map работал, как предложил @dosofredriver, Option бы банально не был бы функтором

Это всё здорово, когда у нас хаскелл. На жвм оно не очень работает. А так да, аргумент хороший.

Это всё здорово, когда у нас хаскелл. На жвм оно не очень работает. А так да, аргумент хороший.

оно везде работает хорошо в смысле "предсказуемо", этими законами пользуется компилятор, когда перехреначивает твои for ы

не пользуется он ими

пользуется, сам мне вчера сказал

максимум -- ожидает наличия

"А я, Олег, знаешь, частенько пользану закон-другой, когда дело за for заходит"

ERROR: S client not available

я могу сделать бредовый контейнер, которым, тем не менее, можно будет заюзать в форе

ДА

Например, Try

Или Future

И получишь херню, которую получишь

Поэтому не делайте бредовых контейнеров

пользуюсь фьючами, все ок меньше фанатизма

Ну все пользуются, всем ок, потому что тут хреновая монада - благоразумие. А портить опшн только ради толики подъёма производительности вопреки здравому смыслу никому не нужно. Просто не используй Option в своём codeforces.

Слушайте, парни, а нельзя разве определить тип, который не будет позволять null? И процессить уже его

Слушайте, парни, а нельзя разве определить тип, который не будет позволять null? И процессить уже его

Как в котлине?

Как в котлине?

Kotlin's type system is aimed to eliminate NullPointerException's from our code. The only possible causes of NPE's may be ... - External Java code has caused it - There's some data inconsistency with regard to initialization (an uninitialized this available in a constructor is used somewhere)

И толку

Ну я не писал почти на нём, не могу прокомментировать.

Слушайте, парни, а нельзя разве определить тип, который не будет позволять null? И процессить уже его

в скале это bottom type и тут все хреново из-за выставления границ типа единственный вариант, который знаю =:=

в скале это bottom type и тут все хреново из-за выставления границ типа единственный вариант, который знаю =:=

bottom type - это Nothing, а не Null

как боттом тип в скале выступают Nothing, Null и брошенные исключения

Null это подтип Nothing строго говоря

В F# можно написать, например type Price=int option

И хрен туда кто уже null прокинет

F# потому что не разрешает использовать null для "своих" типов

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

Вот это реально ударило бы по перфомансу

Фишка в том, что подобное поведение отлавливается на уровне компиляции, по идее

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

Фишка в том, что подобное поведение отлавливается на уровне компиляции, по идее

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

если пересечение их широко

а оно настолько же широко, как сама java

проверок будет очень много

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

С интеропом жопа, согласен

в скале это bottom type и тут все хреново из-за выставления границ типа единственный вариант, который знаю =:=

AnyVal, но он почти всегда не пойдет по ограничениям

Всем привет, ребята! Приятно видеть, что тут приличное такое количество людей Я в Scala новичок, но хочу от нее пропереться :) Сам под Android пишу, даже после Kotlin'a немного голова кружится. В общем, нужен ваш совет. Разрабатываю сервак (scala + play + anorm) Выстроил схему бд и не знаю как быть с моделями. Простой пример - есть сущность Company со стандартными полями типа id, title, и т.д. И есть Product. Связь между ними 1:M. Как лучше организовать модельку Company что бы удобно было делать выборку из бд, фаршировать объект и через api json'ом его отдавать? На гитхабе как то не густо с этим делом. Приличных разжеванных примеров не видно. Или может я не так ищу :)