Я молчу о том, что вопрос в котлине - контрольный символ

Прочитать один вопрос или слово if

там там не только if, еще (), потом else.. куча текста

Ну ссылка - тоже поведение вида: "значение ищи там"

демагогия какая-то

демагогия какая-то

Нет. Просто рассматриваю понятия ссылка с точки зрения теории

там там не только if, еще (), потом else.. куча текста

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

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

+

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

-

тернарный более явный имха

Явное лучше неявного, а в тернарном выражении ещё отыщи разделительные символы - вопрос, двоеточие, они же даже не подсвечиваются

в ифе мусор визуальный

демагогия какая-то

Писать get() у объекта, возвращающий случайное неконсистентное значение - тоже неоднозначное в общем случае решение. А редкие специальные случаи, когда это приемлемо, можно считать исключениями, как мне кажется. :)

о, нашел еще фигню, на которую изредка натыкаюсь, val list: List<Long>=ArrayList()

У вас get декларирует, где брать значение => он является ссылкой на значение

Может и нет. Он может бросить исключение, например. Да, можно весь мир рассмотреть с той позиции, что всё — ссылка, только это ничего нам не даст.

в ифе мусор визуальный

А тернарник тяжело читается и сливается, даже если в ИДЕ есть подсветка, односимвольные операторы плохо выделяются визуально.

о, нашел еще фигню, на которую изредка натыкаюсь, val list: List<Long>=ArrayList()

val list = arrayListOf<Long>()

Может и нет. Он может бросить исключение, например. Да, можно весь мир рассмотреть с той позиции, что всё — ссылка, только это ничего нам не даст.

Может бросить. Это значит, что ссылка не резолвится. Нет, не всё есть ссылка. Если для val объявляется кастомный геттер - значит мы хотим, чтобы значение по ссылке резолвилось. При этом мы не можем val инициализировать конкретным значением.

о, нашел еще фигню, на которую изредка натыкаюсь, val list: List<Long>=ArrayList()

Кроме решения сверху, а в чем проблема?

val list = arrayListOf<Long>()

да не, пофиг что, какой тип, <Any>=whatEver() - не работает, нужен пробел

да не, пофиг что, какой тип, <Any>=whatEver() - не работает, нужен пробел

А можно почеловекочитаемее?

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

недавно прекрасный ифчик нашел

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

Так это просто изначально плохой неидиоматичный код

Так это просто изначально плохой неидиоматичный код

просто пример с листом

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

А даже если не с листом, у тебя ж тип разрезолвится из выражения справа?

недавно прекрасный ифчик нашел

а что, с тернарником было бы лучше?

ну может мне хочется его руками написать

а что, с тернарником было бы лучше?

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

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

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

ну может мне хочется его руками написать

Любой язык можно сломать очень странными относительно парадигмы языка желаниями. :)

а котлин во многом сокращает синтаксис джавы, только в тернарниках не сокращает (мне лично это не биг дил)

Любой язык можно сломать очень странными относительно парадигмы языка желаниями. :)

не писать пробел - очень странное желание?

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

ну это же чат, должен быть треп

не писать пробел - очень странное желание?

Писать объявление+присвоение переменной так - очень странное желание, кажется

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

Ну так вся проблема в том, что его добавляют туда, где он не нужен

лучше так чем ответы на вопросы ленивых джунов

Давайте заведём отдельный чат "Тернарник в Kotlin" и будем туда направлять всех желающих пообсуждать, как обычно отправляют в @pofftop?

лучше так чем ответы на вопросы ленивых джунов

Ленивых джунов, по-моему, меньше, чем любителей пофлеймить, их игнорировать проще, чем 100+ сообщений в очередной раз.

Ленивых джунов, по-моему, меньше, чем любителей пофлеймить, их игнорировать проще, чем 100+ сообщений в очередной раз.

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

А можно ссылку на это заявления Бреслва. А то может рано плачем?

Видео пока не в публичном доступе, поэтому вот транскрипт для этого вопроса (Сессия блиц-вопросов Бреславу на TechTrain): - Здравствуйте Андрей. If-else вот этот вот, двоеточие, вопросик, когда будут реализованы? - А, окей, окей. Да, значит у нас... У нас в последнее время с коммьюнити и всеми другими людьми, которые вообще могут задавать вопросы, есть такая игра: вот предлагают задать вопросы и сразу же кто-нибудь спрашивает про тернарный оператор. Значит, я не могу пообещать точно, но наверное тернарный оператор всё-таки появится в какой-то момент в Котлине относительно скоро. Но не очень скоро, завтра не появится. - Это из-за того, что вас просят, или вам самим хочется? - Ну, мне не хочется, но просят-то не просто так. Действительно, удобно иметь тернарный оператор. Я вам верю, удобно. Его не так-то просто удобно впихнуть в язык, но вроде мы придумали как примерно, так что скорее всего всё получится.

Ну так вся проблема в том, что его добавляют туда, где он не нужен

Я-то согласен, но когда последний раз такой спор привёл к результатам? :)

Да спорить нужен тернарник или нет, всё равно что спорить, писать ли типы слева или справа

This ^

Добрый день. Подскажите как правильно с помощью операторов коллекций Котлина реализовать след. задачу: есть 2 списка int. В первом 10 элеменов, во втром допустим 3. Нужно из первого списка убрать все элементы, которые есть во втором списке(если они есть). Я так понимаю нужно закомбинить .filter и .foreach, но чет у меня неправильно выходит походу. Вот код: val list2 = idLongList.filter { oldId -> transactionState.unabledFines.forEach { oldId != it } }

Видео пока не в публичном доступе, поэтому вот транскрипт для этого вопроса (Сессия блиц-вопросов Бреславу на TechTrain): - Здравствуйте Андрей. If-else вот этот вот, двоеточие, вопросик, когда будут реализованы? - А, окей, окей. Да, значит у нас... У нас в последнее время с коммьюнити и всеми другими людьми, которые вообще могут задавать вопросы, есть такая игра: вот предлагают задать вопросы и сразу же кто-нибудь спрашивает про тернарный оператор. Значит, я не могу пообещать точно, но наверное тернарный оператор всё-таки появится в какой-то момент в Котлине относительно скоро. Но не очень скоро, завтра не появится. - Это из-за того, что вас просят, или вам самим хочется? - Ну, мне не хочется, но просят-то не просто так. Действительно, удобно иметь тернарный оператор. Я вам верю, удобно. Его не так-то просто удобно впихнуть в язык, но вроде мы придумали как примерно, так что скорее всего всё получится.

заль

Писать объявление+присвоение переменной так - очень странное желание, кажется

как дефолтное значение аргумента метода сойдет?

Да спорить нужен тернарник или нет, всё равно что спорить, писать ли типы слева или справа

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

Ну спор "тернарник vs if-expression" действительно бесполезный, вот только первоначальная цепочка заявлений была "котлин состоит из костылей и подпорок к ним, что он построен на этом<...> например, там нет тернарного оператора"

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

Мне один товарищ жаловался, что мол зачем типы справа, это ведь целых четыре лишних символа писать для val

Вообще-то система типов (кроме некоторых случаев) в Котлине очень хорошо сделана. В среднем, да, мы пишем больше символов из-за val/var, но зато экономим ОЧЕНЬ много, когда типы выводятся автоматически

Мне один товарищ жаловался, что мол зачем типы справа, это ведь целых четыре лишних символа писать для val

меня это больше в смешанных проектах (котлин/джава) беспокоит, под утро бывает тяжело понять как писать в этом конкретном файле =)

как дефолтное значение аргумента метода сойдет?

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

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

вроде речи не было о дженерик

Добрый день. Подскажите как правильно с помощью операторов коллекций Котлина реализовать след. задачу: есть 2 списка int. В первом 10 элеменов, во втром допустим 3. Нужно из первого списка убрать все элементы, которые есть во втором списке(если они есть). Я так понимаю нужно закомбинить .filter и .foreach, но чет у меня неправильно выходит походу. Вот код: val list2 = idLongList.filter { oldId -> transactionState.unabledFines.forEach { oldId != it } }

val xs = (1..10).toList() // 10 элементов val ys = listOf(1, 5, 7) // 3 элемента val filter = xs.filter { it !in ys } println(filter)

вроде речи не было о дженерик

Проблема же в склейке закрывающейся угловой скобки и = была.

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

Да запросто - foo: List<String> = emptyList() Но я сам привык писать пробелы, поэтому не замечал проблем.

val xs = (1..10).toList() // 10 элементов val ys = listOf(1, 5, 7) // 3 элемента val filter = xs.filter { it !in ys } println(filter)

точно! забыл про in, спасибо!

Добрый день. Подскажите как правильно с помощью операторов коллекций Котлина реализовать след. задачу: есть 2 списка int. В первом 10 элеменов, во втром допустим 3. Нужно из первого списка убрать все элементы, которые есть во втором списке(если они есть). Я так понимаю нужно закомбинить .filter и .foreach, но чет у меня неправильно выходит походу. Вот код: val list2 = idLongList.filter { oldId -> transactionState.unabledFines.forEach { oldId != it } }

Вы не поверите :) list1 - list2 успешно справляется с задачей. https://pl.kotl.in/HJ2gBbc57

Проблема же в склейке закрывающейся угловой скобки и = была.

а, ну вот банально param: List<X> = emptyList()

Вы не поверите :) list1 - list2 успешно справляется с задачей. https://pl.kotl.in/HJ2gBbc57

Кстати да

Что нам обсудить ? Мы говорим ненужно, ты нужно, мы тебе "а для чего, как часто используешь", ты "зачем мне пруфы давать". На этом все, извини

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

а, ну вот банально param: List<X> = emptyList()

Так дженерик тип и у конструктора можно указать

ERROR: S client not available

Так дженерик тип и у конструктора можно указать

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

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

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

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

"мне кажется" — это не аргумент. Уже несколько человек отметилось с мыслью, что это плохая идея. Предложили сходить в #stdlib и пообщаться там, получив более релеватные ответы, если текущий чат не устраивает. В худшем случае, если это кажется таким полезным, но сообщество не понимает, можно написать одну несчастную функцию forever(...) и использовать её, расстраиваясь, что язык хреновый. Что ты тут-то до сих пор делаешь, если видишь, что дискуссия в тупик давно зашла?

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

а откуда он возьмётся, если не указать? В параметрах не выведется.

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

Не нужно, ибо если кому-то вдруг понадобится делать кучу бесконечных циклов, всегда можно сделать так: inline fun loop(action: () -> Any?) { while (true) action() } ... loop { println("foo") }

Вот чего точно не хватает в языке, например в таких случаях: when(some=fun()) {.... cases with some }

причем с ограничением области видимости переменной блоком when

не оч понел о чем ты

а откуда он возьмётся, если не указать? В параметрах не выведется.

А, ну да Странно, мне всегда казалось, что можно написать val list: List = emptyList<X>()

Да, касательно присваивания-выражения согласен, чуть ли не единственная штука, которая огорчает. И то решается несчастным while(true) { val value = expr ?: break; ... }.

Не нужно, ибо если кому-то вдруг понадобится делать кучу бесконечных циклов, всегда можно сделать так: inline fun loop(action: () -> Any?) { while (true) action() } ... loop { println("foo") }

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

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

> часто возникает нет /thread

Да, касательно присваивания-выражения согласен, чуть ли не единственная штука, которая огорчает. И то решается несчастным while(true) { val value = expr ?: break; ... }.

ой вэй а нельзя просто фигурные скобки? даже в си можно. до этого кстати do while false использовали

ой вэй а нельзя просто фигурные скобки? даже в си можно. до этого кстати do while false использовали

В котлине тоже можно. Только это ж не цикл. UPD: а ведь действительно нельзя, это ж определение лямбды. Oh well, значит настолько часто мне эта фича нужна.

> часто возникает нет /thread

вопрос частоты не единственный. если это все что тебя волнует, я тебя понел, спасибо.

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

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

> часто возникает нет /thread

часто, с корутинами например

бесконечно раз в 10 сек что-нибудь чекаем пока скоп не помер

часто, с корутинами например

С корутинами частно должно возникать while(isActive), а не бесконечные циклы.

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

Мне кажется, или я уже видел это вчера? Пора прекращать.

С корутинами частно должно возникать while(isActive), а не бесконечные циклы.

см, пример выше

что за isActive, си стайл какой-то, у нас же структурная канкаренси

вопрос частоты не единственный. если это все что тебя волнует, я тебя понел, спасибо.

1) Про частоту использования мы всё сказали 2) Импакт равен шести символам и ничему более То есть да, микроштука, которая регулярно проявляется только на специфичном срезе приложений, полностью синонимичная короткой и однозначной более популярной конструкции языка - не нужна.

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

какой-то странный аргумент про сахар. пишите на жаве, а то в котлине стока сахара

что за isActive, си стайл какой-то, у нас же структурная канкаренси

И то верно. Я со времён её введения корутинами не занимался, увы.

ой вэй а нельзя просто фигурные скобки? даже в си можно. до этого кстати do while false использовали

Можно run { }. А для себя можно было бы уже давно написать loop { } и закрыть тему.

Да, уже раза три предложили.

Да, уже раза три предложили.

Думаю, больше.

Думаю, больше.

Новая тема для спора!

Думаю, больше.

а вы не пробовали понять что я не про себя а про стдлиб?

Новая тема для спора!

Вообще-то, четыре

а вы не пробовали понять что я не про себя а про стдлиб?

Без разницы.

А выглядеть он должен, как мне кажется, так: fun loop(block: () -> Unit): Nothing