хуже маркера сложно что-то придумать

А для when по sealed разве не тот же instanceof используется?

sealed даже для использующих его jar-ников перестаёт быть таковым, ибо компилятор теряет гарантию, что он перечислил всех наследников и больше наследников быть не может.

А для when по sealed разве не тот же instanceof используется?

где-то была задача сделать switch на интах, но я не нахожу

sealed даже для использующих его jar-ников перестаёт быть таковым, ибо компилятор теряет гарантию, что он перечислил всех наследников и больше наследников быть не может.

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

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

Идея в этом месте варнингом плюётся как раз.

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

а что осмысленного можно сделать в else? Упасть на рантайме?

а что осмысленного можно сделать в else? Упасть на рантайме?

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

а что осмысленного можно сделать в else? Упасть на рантайме?

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

А для when по sealed разве не тот же instanceof используется?

INSTANCEOF там, да

А может, и сообщить, куда полагается ?

Ну то есть sealed по сути от маркер-интерфейса по производительности не отличается ничем и полезен только в рамках одного модуля и только для того, чтобы компилятор по пальцам ударил.

где-то была задача сделать switch на интах, но я не нахожу

интересная идея

Ну то есть sealed по сути от маркер-интерфейса по производительности не отличается ничем и полезен только в рамках одного модуля и только для того, чтобы компилятор по пальцам ударил.

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

@KirillTim, признавайся, оптимизируется там что-то или нет?)

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

ну рантаймом тогда уж

@KirillTim, признавайся, оптимизируется там что-то или нет?)

это не ко мне :) я не знаю, честно говоря

это не ко мне :) я не знаю, честно говоря

Эх. Я надеялся, инсайды соседних команд шарить тут будешь... ?

Эх. Я надеялся, инсайды соседних команд шарить тут будешь... ?

:)

Надо собрать, декомпилить и посмотреть, что как дети то :) где тут инженеры?)

Будь я у компа уже бы пошарил

Эх. Я надеялся, инсайды соседних команд шарить тут будешь... ?

я знаю когда будет релиз 1.3 )))

я знаю когда будет релиз 1.3 )))

Когда?)

Но нам не скажешь, потому что у нас докУментов нету, я полагаю?)

Когда?)

не скажу

Но нам не скажешь, потому что у нас докУментов нету, я полагаю?)

ага

не скажу

Э, сказал а- говори бэ)

Да ладно, 1.3-M1 есть -- и на том спасибо.

Мне больше интересно, будут ли громкие новости по K/N на KotlinConf ?

заглянул еще раз в доку и там ... Note that classes which extend subclasses of a sealed class (indirect inheritors) can be placed anywhere, not necessarily in the same file.

эх вот бы ртфм в 2018

Надо собрать, декомпилить и посмотреть, что как дети то :) где тут инженеры?)

декомпильнут опенсорсный компилятор?

декомпильнут опенсорсный компилятор?

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

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

а, ну это вообще обязательное занятие в начале знакомства

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

+

+

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

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

Не, надо while декомпильнуть

Не, надо while декомпильнуть

а что кроме ifeq goto можно увдеть?

В рантайме будет просто набор классов это же jvm

а что кроме ifeq goto можно увдеть?

+

все верят в "магию"

а сайлед классы досих пор запрещаются наследоватся из разных файлов, ну если не повешать анноташку ?

а что кроме ifeq goto можно увдеть?

Например проверку на выход из набора классов. Null checks как в рантайме работают? Идет проверка аргумента в utility классах

а сайлед классы досих пор запрещаются наследоватся из разных файлов, ну если не повешать анноташку ?

вроде че-то меняли с ними, надо смотреть

Например проверку на выход из набора классов. Null checks как в рантайме работают? Идет проверка аргумента в utility классах

а разве это не должен делать компилятор ?

а разве это не должен делать компилятор ?

так о нём и речь

так о нём и речь

а я про байт-код )

а я про байт-код )

ну, компилятор генерирует байт-код :)

Например проверку на выход из набора классов. Null checks как в рантайме работают? Идет проверка аргумента в utility классах

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

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

@SchFuntik ты мне сейчас что то хочешь доказать или убедить в чем то?

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

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

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

ну тут были "оптимизации", так то все хорошо, полезная фича

@SchFuntik ты мне сейчас что то хочешь доказать или убедить в чем то?

нет

Кстати, где можно посмотреть развернутый ответ на вопрос "Почему в Kotlin нельзя определять свои операторы?", только без стандартных ответов "потому что Kotlin не Scala"

типа набо для оператор оверлоадинг ограничен или что?

Кстати, где можно посмотреть развернутый ответ на вопрос "Почему в Kotlin нельзя определять свои операторы?", только без стандартных ответов "потому что Kotlin не Scala"

потому-что котлин не с++ ?

Кстати, где можно посмотреть развернутый ответ на вопрос "Почему в Kotlin нельзя определять свои операторы?", только без стандартных ответов "потому что Kotlin не Scala"

ну мое имхо, очеть сложно потом будет читать как чужой так и свой код

потому-что котлин не с++ ?

А c++ разве можно определять операторы?

Кстати, где можно посмотреть развернутый ответ на вопрос "Почему в Kotlin нельзя определять свои операторы?", только без стандартных ответов "потому что Kotlin не Scala"

а инфиксные функции не помогут?

А c++ разве можно определять операторы?

ой да, ошибочка)

Кстати, где можно посмотреть развернутый ответ на вопрос "Почему в Kotlin нельзя определять свои операторы?", только без стандартных ответов "потому что Kotlin не Scala"

Потому что котлин НЕ функциональный язык (с) Бреслав ? А для всего остального есть методы (плюс базовый набор операторов).

а инфиксные функции не помогут?

1) Сложно читать код на инфиксных функциях, ты не отделишь данные от операций над ними (визуально) 2) нет приоритетов

ERROR: S client not available

1) Сложно читать код на инфиксных функциях, ты не отделишь данные от операций над ними (визуально) 2) нет приоритетов

А неизвестный символ читать проще?

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

ну а чем они будут тогда отличаться от инфиксных функций? )

А неизвестный символ читать проще?

Если у тебя есть знакомый тебе dsl, то чтение облегчается в разы

ну а чем они будут тогда отличаться от инфиксных функций? )

_альтернативные_ человекочитаемые имена*

Тут скорее всего дело в каком-нибудь компромиссе между хорошей фичей и последствиями от неё же

Тут скорее всего дело в каком-нибудь компромиссе между хорошей фичей и последствиями от неё же

+

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

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

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

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

В Scala?)

единственое что мне не хватая так это сетера

Контрл клик по оператору

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

Если есть алиасы, как я описал выше, то никто не запрещает использовать их. Ты ведь и сейчас можешь писать list + element, а можешь list.plus(element)

Контрл клик по оператору

+

Контрл клик по оператору

ну тогда "декларативностью" и пахнуть не будет

Зато красиво

Зато красиво

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

В Scala?)

нет в котлин если появится

Если есть алиасы, как я описал выше, то никто не запрещает использовать их. Ты ведь и сейчас можешь писать list + element, а можешь list.plus(element)

смысл тогда в них ? одни будут писать по одному, другие по другому, по факту Г код

Опять же если оператор определен, то смысл использовать алиас

смысл тогда в них ? одни будут писать по одному, другие по другому, по факту Г код

Если работать в одиночку, а не в команде, то никаких проблем не вижу

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

Если работать в одиночку, а не в команде, то никаких проблем не вижу

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

ну и по факту тогда зачем будет нужна скала ?

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

У меня очень хорошая память))

У меня очень хорошая память))

сожалению не всем так повезло)

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

а я всегда под одним и тем же =)

Опять же если оператор определен, то смысл использовать алиас

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

как раз тут можно и нужно дать право выбора

а вот еще один минус, придумали оператор, ок. JB решила тожее ввести оператор или ключевое слово с такимже именем, и вы решили перейти на новую версию. Вопрос, как быстро вы перейдете.

У меня очень хорошая память))

Или проекты мелкие... Бывает только на поиск чего-то уходит по пол часа, не то что бы вспомнить...