фп никак не противоречит null

ага и в scala тоже

На практике в Scala за null бьют примерно так же как за var, если этот var не стейт актора.

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

скала это не чистый фп язык

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

пруфы? чтоле раз такой разговор зашел

На практике в Scala за null бьют примерно так же как за var, если этот var не стейт актора.

ну да, но на практике можно понаписать всякого, и нуллы будут на ура. Дык вот поэтому и вопрос - почему нет Required

/scala

фп не фп имхо не важо, тут вопрос про типизацию

мне кажется разгооры про чистоту скалы (лол она грязна = сайдэффектовая) это оффтоп

да

а использовать не использовать нулы это уже кейсы

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

фп не фп имхо не важо, тут вопрос про типизацию

да да, и монадки заодно.

потому что ты не сможешь реализовать Required, который будет тебе обеспечивать отсутсвие null в compile time. а в рантайме проверять то же самое что проверять на null

чойта?

опшн вроде тоже это не обеспечивает

ну да, но на практике можно понаписать всякого, и нуллы будут на ура. Дык вот поэтому и вопрос - почему нет Required

В послдений раз NPE я видел пару месяцев назад, когда юзал NIO2 без оберток. В Scala коде ни кто оне возвращает null. Это как "goto" и "глобальные переменные".

а Erlang эт функциональный язык?

блин ну не каждый фп язык чист

окамл не чистый

да что за бред

null вообще ортогонален ФП

В послдений раз NPE я видел пару месяцев назад, когда юзал NIO2 без оберток. В Scala коде ни кто оне возвращает null. Это как "goto" и "глобальные переменные".

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

В послдений раз NPE я видел пару месяцев назад, когда юзал NIO2 без оберток. В Scala коде ни кто оне возвращает null. Это как "goto" и "глобальные переменные".

а нех напрямую nio юзать)

на прямую?

Не очень понял вопрос. Во втором случае будет что-то типа { "subModel": { "d1": {"field1": 10, "field2": [2,3,4,5,6,6,7]} }, "i": 5, "str": "some string value" }

Так не работает у меня. Прошел только вариант, который в гисте. Хотелось же, чтобы обрабатывался вариант { "subModel": {"field1": 10, "field2": [2,3,4,5,6,6,7]}, "i": 5, "str": "some string value" }

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

а если чел уже свалил с конторы, вопрос что бить: 1. искать чела? 2. бить монитор? 3. бить соседа? ...

исправить кож

код

не бить, а читать

читать и читать русскую классику

пару десятков тысяч строк кода - оо это будит весело)

пока "на прямую" не превратится в НАПРЯМУЮ

кончайте уже с налами) это бед стайл офк

пока "на прямую" не превратится в НАПРЯМУЮ

я ж поправился, лошара

чуваки я поэтому и спрашиваю - почему бед стайл не исправили на уровне компилятора. Ежу понятно что можно писать по соглашениям и осторожно и всё будет ок

местами null очень даже ничего

Так не работает у меня. Прошел только вариант, который в гисте. Хотелось же, чтобы обрабатывался вариант { "subModel": {"field1": 10, "field2": [2,3,4,5,6,6,7]}, "i": 5, "str": "some string value" }

В таком случае только кастомные Reader/Writer :( Дело в том что если так сделать, то не понятно как обрабатывать случаи типа case class E(s1: D, s2: D)

чуваки я поэтому и спрашиваю - почему бед стайл не исправили на уровне компилятора. Ежу понятно что можно писать по соглашениям и осторожно и всё будет ок

потому что интероп с джавой

ну и иногда оверхед от налла опаснее самого налла

а если чел уже свалил с конторы, вопрос что бить: 1. искать чела? 2. бить монитор? 3. бить соседа? ...

постараться найти все "точки входа" этих null и обернуть их в Option. Все, компилятор теперь сам скажет, где возможна проблема

а если чел уже свалил с конторы, вопрос что бить: 1. искать чела? 2. бить монитор? 3. бить соседа? ...

Этот код должен был не пройти ревью вот и все :)

*оверхед от опшна, конечно

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

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

Конечно.

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

hz как копмпилить код если у тебя в зависимостях какая джава либа

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

ой как trait совместимы )

ахах)

ну все все

:D

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

Обычно это решают запихиванием поля "$type ": "com.example.D.D1" но меня от такого в дрож бросает.

Конечно.

Ясно. Был еще момент с привидением имени класса к имени поля. Clazz превратится в "clazz", а MyClazz я так и не осилил. Пришлось в одно слово называть (хотя читаться стало лучше в конкретном месте =) )

Ясно. Был еще момент с привидением имени класса к имени поля. Clazz превратится в "clazz", а MyClazz я так и не осилил. Пришлось в одно слово называть (хотя читаться стало лучше в конкретном месте =) )

MyClazz должен был превратиться в myClazz.

Обычно это решают запихиванием поля "$type ": "com.example.D.D1" но меня от такого в дрож бросает.

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

Сейчас сработало в воркшите, дома почему-то сфейлился. Спасибо за помощь.

Обычно это решают запихиванием поля "$type ": "com.example.D.D1" но меня от такого в дрож бросает.

а почему в дрож бросает?) можно ж передавать не класснеим

а почему в дрож бросает?) можно ж передавать не класснеим

Не люблю служебную информацию в человекочитаемых форматах. Стараюсь ее максимально облагородить. Могу объяснить, почему в пушке сделаны вот такие конструкции { "fieldName": { "childOfSealedTrait": { ... } } }. Дело в том, что я обратил внимание, что у нас в проектах, почти везде во внешнем API, где используется перечисление на силед трейтах, наследники это либо кейсобжекты либо кейс-классы с одни полем. Кейс-обжекты пишутся как строки, а кейс-классы с одни полем пишутся без объекта-обертки ( case class Foo(x: Int = 1) --> 1 ). По этому такая запись получается компактной: { "fieldNameOfSt": "myCaseObject", "anotherFiledNameOfSt": { "foo" : 1 } }.

http://www.lihaoyi.com/post/BenchmarkingScalaCollections.html

любопытно сравнение Map/Set с их мутабельными аналогами, все совсем плохо

на 1024 элементах все одинаково

для меня шок, что вроде как на больших обьемах юзаются деревья

кто-то обьяснит, зачем?

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

На больших объёмах хеш таблица получше будет =)

ERROR: S client not available

ну как видно, не особо те гарантии и норм

Вообще я бы не стал данной статье доверять. Поскольку не может массив интов и лонгов в памяти одном место занимать

ну автор вроде шарит я пока не проверял вдумчиво

так у него и нет одинакового

разные объемы

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

Как нет

Размер 1

Лонг и инт равны

ну к результатам доверия не добавляют числа типа "-200" время доступа

Он написал свою херню, когда есть jol

Нет ему доверия)

я похоже слепой

разные же

Эт саиз 64

А ты смотри саиз 1

Где по 24

и?

Что и? Как такое возможно

выравнивание

Лонг в два раза больше занимает, не?

выравнивание идет на 8 байт

те что бит с байтом одинаково весят, тебя не смущает?)

(а это уже претензии к джвм)

Не причём тут жвм

И какое выравнивание)))))

Не логично оно там, вроде каа

джвм все выравнивает для кратности 8, как это она ни при чем

(оракл/опен, по крайней мере)

пустой массив 16 байт дальше добавляют один элемент от 1 до 8 байт но за счет выравнивания на 8, они все одинаковые

Ща постом посчитаю на бумажке