я как то попривык в джаве =)

а мне вот дико не нравится в котлине весь этот замут с нулабл =)

Мне тоже не нравился, долго от него плевался, а потом понял что это вещь. :)

Ну просто что бы код на котлине был не блювотный приходится логику менять по сравнению с явой, иначе будет пестрить от "?"

Мне тоже не нравился, долго от него плевался, а потом понял что это вещь. :)

Да, я вчера тоже это понял когда писал хз какую по счету проверку на нал )

Закройте глаза чтобы не выколить их

Так а что не так с кодом то?) Мне интересно уже

Ну просто что бы код на котлине был не блювотный приходится логику менять по сравнению с явой, иначе будет пестрить от "?"

А вы реорганизуйте логику. :) И норм будет

Да, я вчера тоже это понял когда писал хз какую по счету проверку на нал )

Сарказм?)

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

Многострочнaя лямбда для однострочной функции, List#forEach, который чуть медленее, насколько я помню

Сарказм?)

Не, чего?) ?. - не хватает мне на жаве

А вы реорганизуйте логику. :) И норм будет

ну это понятно, я в своём сообщение как раз и писал что без переделки никак

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

> без нулабл типов можно было бы обойтись Ну такое. :)

ну и конечно же как не сказать про царицу полей =) про тернарный наш оператор (или как он там называется) =)

Тернарный )

ну и конечно же как не сказать про царицу полей =) про тернарный наш оператор (или как он там называется) =)

Лично я оч редко юзаю if else как тернарный. :)

Тернарный )

спс

Больше when

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

тем более кодестайл котлин-андроид это запрещают =)))

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

Если короткая строка - лучше в одну, если длинная - имхо, но if else выглядит убого, when лучше.

ага, всегда хотелось перепилить энамы

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

хероввый дев, к сожалению, пишет wtf?.fuck?.damn()

Если короткая строка - лучше в одну, если длинная - имхо, но if else выглядит убого, when лучше.

иф в одну строку всегда херово - потому что там не {} - а без этого можно потом при рефакторинге дел натворить =))))

хероввый дев, к сожалению, пишет wtf?.fuck?.damn()

Ну вот не соглашусь. Иногда такая запись очень даже кстати.

хероввый дев, к сожалению, пишет wtf?.fuck?.damn()

ага, и у него даже не падает =) я вот про это как раз =)

Ну вот не соглашусь. Иногда такая запись очень даже кстати.

Ну, при взаимодействии с легсаи-кодом.

иф в одну строку всегда херово - потому что там не {} - а без этого можно потом при рефакторинге дел натворить =))))

Каких дел?

Каких дел?

ну это не совсем по это, а про кейс когда if без {}, но не в одну строку, когда бабезян коментит (удаляет) то что под ифом и код начинает очень странно работать. Кейснемного другой, но всё равно мне (да и судя по гкодестайлам от гугла - не только мне) стрёмно иф без скобок писать

проще как и делает гугл - запретить писать иф без {}

проще как и делает гугл - запретить писать иф без {}

Это тупо

это примерно как нулб в котлине

Что делать? Запретить «бабезян»? :)

тупо и мешает

тупо и мешает

Ну если всё делать нуллабельным, то, конечно, мешает. Профит в том, чтобы делать не-нуллабельным :)

Ну если всё делать нуллабельным, то, конечно, мешает. Профит в том, чтобы делать не-нуллабельным :)

да что вы говорите =))))))

А вообще, мне всегда хочется выставить наружу unmodifiableList(Arrays.asList(values())), но тоже говнокод получается.

да что вы говорите =))))))

Если вы не смогли научится писать в парадигме где существует not nullable, то это уже ваша проблема. Для чего же завезли в Java уродливый Optional? Он лучше будет выглядеть?

как это: lateinit var allRadio: NodeList allRadio = document.querySelectorAll(".radio-inline") превратить в Array / List из HtmlElement что бы можно было использовать .forEach{ it.onclick = {} }

как NodeList превратить в обычный котлиновский List

Если вы не смогли научится писать в парадигме где существует not nullable, то это уже ваша проблема. Для чего же завезли в Java уродливый Optional? Он лучше будет выглядеть?

А как же @NotNull и @Nullable

А как же @NotNull и @Nullable

Плохо. Поменял в одном месте — а всё равно компилируется.

Плохо. Поменял в одном месте — а всё равно компилируется.

Так потому что компилятору чихать на эти аннотации

И это главная проблема - nullable везде, но никто не тыкает тебя в этот факт

отсюда и извечные NPE

как это: lateinit var allRadio: NodeList allRadio = document.querySelectorAll(".radio-inline") превратить в Array / List из HtmlElement что бы можно было использовать .forEach{ it.onclick = {} }

Это что за либа? Хотя в любом случае можно взять что-то на подобие val xs = List(nodes.length, nodes::item) xs.forEach { it.onclick = {} }

Если вы не смогли научится писать в парадигме где существует not nullable, то это уже ваша проблема. Для чего же завезли в Java уродливый Optional? Он лучше будет выглядеть?

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

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

Не в андроид не завезли, а версия джавы не позволяет. Слова (аргументы) без доводов - пустой трёп. И если вам не нравится что-то, то потрудитесь обосновать это, а не разводит базар

Не в андроид не завезли, а версия джавы не позволяет. Слова (аргументы) без доводов - пустой трёп. И если вам не нравится что-то, то потрудитесь обосновать это, а не разводит базар

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

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

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

1. Это делает код менее красивым если вы пишите на Kotlin как на Java, этот оператор лишь замена if (obj != null), что точно менее красиво будет. 2. Обычно такое нужно лишь где мы сами понимаем что может быть null или где у нас граница с Java, значения с которой необходимо интерпретировать как nullablr тип

Я думаю что not nullable by default лучше nullable by default просто потому что явное лучше неявного.

1. Это делает код менее красивым если вы пишите на Kotlin как на Java, этот оператор лишь замена if (obj != null), что точно менее красиво будет. 2. Обычно такое нужно лишь где мы сами понимаем что может быть null или где у нас граница с Java, значения с которой необходимо интерпретировать как nullablr тип

да-да это всё так ) но имха, это лишнее =)

да-да это всё так ) но имха, это лишнее =)

Лишнее - это писать код, который работает неизвестно как. А если твой взгляд вечно цепляется за вопросы - ты рано или поздно задумаешься "А всё ли с этим кодом в порядке?"

я молчу о том, что в котлине завезли smart cast, let/also/... и прочие красивости

Ну дык, кто мешает в java написать код который работает изветно как? =)

Так я и не говорю что не используйте котлин

я не разу не сказал что котлин плох

Ну дык, кто мешает в java написать код который работает изветно как? =)

Не кто, а что - тот факт, что ты не один в команде, но тебя одного хватит, чтобы наляпать ошибок с NPE в неожиданных местах

Вам видимо нравится NullPointer)

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

Вам видимо нравится NullPointer)

когда нормально пишешь их нет =)

Ну конструкция Int? выглядит значительно проще, чем возня с Optional. Легче читается, плюс идет в унисон с другими популярными языками (C#, PHP)

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

Быдлокодерам пофигу на null/notnull

когда нормально пишешь их нет =)

Ты ни разу их не ловил?:) чудак-человек

Не кто, а что - тот факт, что ты не один в команде, но тебя одного хватит, чтобы наляпать ошибок с NPE в неожиданных местах

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

Ты ни разу их не ловил?:) чудак-человек

ну при дебаге да конечно =)

Если ты убеждён, что ты супермен, который может писать на Java на 100% без NPE - дело твоё:) а я привык лишний раз подстраховаться, вместо того, чтобы быть таким самоуверенным

Подскажите как получить тип класса у которого есть входящие параметры ?

Это что за либа? Хотя в любом случае можно взять что-то на подобие val xs = List(nodes.length, nodes::item) xs.forEach { it.onclick = {} }

обычная Kotlin-js std, document.querySelectorAll(".radio-inline") это же js

Подскажите как получить тип класса у которого есть входящие параметры ?

что?

Если ты убеждён, что ты супермен, который может писать на Java на 100% без NPE - дело твоё:) а я привык лишний раз подстраховаться, вместо того, чтобы быть таким самоуверенным

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

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

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

что?

val claz = Class().javaClass но в Class() требует передать переменную, так что ошибка.

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

когда ты вызываешь метод из либы ? У которой еще вызов 256 ?

когда ты вызываешь метод из либы ? У которой еще вызов 256 ?

ну там я проверю на нул =)

val claz = Class().javaClass но в Class() требует передать переменную, так что ошибка.

откуда тебе нужно получить клаcс ?

когда ты вызываешь метод из либы ? У которой еще вызов 256 ?

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

ну там я проверю на нул =)

и их в итоге 256 штук этих проверок

и их в итоге 256 штук этих проверок

или врапер вокруг либы =)

откуда тебе нужно получить клаcс ?

val claz = ЛюбойКлассСВходящей Переменной().javaClass

в общем мне кажется я донёс своё мнение, ваше мнение я тоже понял, пойду слив у умывальника мутить =))))

с принимающей*

в общем мне кажется я донёс своё мнение, ваше мнение я тоже понял, пойду слив у умывальника мутить =))))

ты говоришь, что можешь предугадать 100% NPE, мы говорим, что лучше подстрахуемся

вот и всё

При nullable by default ты не можешь быть уверен что внутри цепочки вызовов где-то [ошибочно] все-таки проскочит null. Хуже того - когда конкретно твой код завалится (или код, базированный на твоем завалится) - проблема будет недостаточно локализована. Скорее всего, ты добавишь проверку на null у себя, либо же уйдешь в дебри разбираться откуда в цепочке null взялся. Not nullable by default гарантирует идеальную точность локализации проблемы. Компилятор не пропустит передачу nullable аргумента в параметр который объявлен как not nullable. Это элементарное quality of life улучшение которое экономит время на дебаге.

нашел https://kotlinlang.org/api/latest/jvm/stdlib/org.w3c.dom/-radio-node-list/index.html

val claz = ЛюбойКлассСВходящей Переменной().javaClass

что бы получить класс, можно заюзать obj::class.java

При nullable by default ты не можешь быть уверен что внутри цепочки вызовов где-то [ошибочно] все-таки проскочит null. Хуже того - когда конкретно твой код завалится (или код, базированный на твоем завалится) - проблема будет недостаточно локализована. Скорее всего, ты добавишь проверку на null у себя, либо же уйдешь в дебри разбираться откуда в цепочке null взялся. Not nullable by default гарантирует идеальную точность локализации проблемы. Компилятор не пропустит передачу nullable аргумента в параметр который объявлен как not nullable. Это элементарное quality of life улучшение которое экономит время на дебаге.

Согласен

что бы получить класс, можно заюзать obj::class.java

пасиб, то что надо )

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

Плюс, not nullable by default облегчает взаимодействие с чужими кусками кода (и речь не о количестве работников на проекте - мы еще также используем чужие либы) которые не null-safe. Если ты пытаешься интегрировать не null-safe результат внутрь своей null-safe кодбазы, компилятор заставит тебя сделать проверку еще на самой первой точке входа, и далее ты будешь работать в полностью безопасном режиме. Если в процессе рефакторинга эта проверка потеряется - опять же, проект даже не скомпилируется. Без null-safety, ты либо вынужден, как писали выше, пихать проверки на null при каждом обращении чтобы получить действительно безопасный код, либо же рискуешь совершенно непонятно завалится когда кто-нибудь изменит точку входа и забудет в ней сделать проверку на null.

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

Плюс, not nullable by default облегчает взаимодействие с чужими кусками кода (и речь не о количестве работников на проекте - мы еще также используем чужие либы) которые не null-safe. Если ты пытаешься интегрировать не null-safe результат внутрь своей null-safe кодбазы, компилятор заставит тебя сделать проверку еще на самой первой точке входа, и далее ты будешь работать в полностью безопасном режиме. Если в процессе рефакторинга эта проверка потеряется - опять же, проект даже не скомпилируется. Без null-safety, ты либо вынужден, как писали выше, пихать проверки на null при каждом обращении чтобы получить действительно безопасный код, либо же рискуешь совершенно непонятно завалится когда кто-нибудь изменит точку входа и забудет в ней сделать проверку на null.

Согласен. Ко всему прочему, not nullable by default намного логичнее, ведь когда пишешь, к примеру val user: User то подразумеваешь что там может лежать только User, а не null.

У сторонников nullable by default какая - то инверсия-перверсия приоритета. Алё, immutable, non-nullable, public - это как раз то что чаще всего встречается в коде и требует дефолтности, тут даже обсуждать нечего, это даже не вопрос вкуса

про public поспорил бы

про public поспорил бы

согласен, но все равно благодарен разрабам

я про паблик добавил для пущей весомости доводов )