Сделайте себе либу наподобие https://github.com/czyzby/kotlin-times и радуйтесь whilе'у без true))

Coverage 101% ?

Любой game программист тебе скажет что всем нужны кватернионы, а от комплексных чисел никакой пользы ;)

Три года этого термина не слышал ☺️

Что, с тех пор как теормех закончился?

Coverage 101% ?

Надо нести добро в мир.

Воу, воу, дарт синтаксис приятный? Это когда ; нужно после объявления конструктора ставить?

Это все субъективщина и только

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

Но аргументов ждут от ТЕБЯ, можешь идти создавать issue

Это все субъективщина и только

Субъективщина измеряется размером зарплаты ;)

Субъективщина измеряется размером зарплаты ;)

Прямо или обратно пропорционально?

Субъективщина измеряется размером зарплаты ;)

Если мне будут платить куча бабок за написание кода на "так себе яп", я буду писать, но не буду говорить что он "прекрассен", я буду говорит как есть (субъективно)

Если мне будут платить куча бабок за написание кода на "так себе яп", я буду писать, но не буду говорить что он "прекрассен", я буду говорит как есть (субъективно)

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

Да нет как бы, сейчас бы в 2018 тратить время на точки с запятыми в самых неожиданных местах

Не так уж субъективно

Если мне будут платить куча бабок за написание кода на "так себе яп", я буду писать, но не буду говорить что он "прекрассен", я буду говорит как есть (субъективно)

Я вобще не припомню ничего идеального. Везде свои недочеты и проблемы. У всего свои цели и своя цена.

Я вобще не припомню ничего идеального. Везде свои недочеты и проблемы. У всего свои цели и своя цена.

+

Там вроде об идеальности речи нет. А то за бабки делать вид, что дерьмовая технология крута - какая то проституция:)

вот так проще: interface Test { val name: String } class TestData(override val name: String) : Test class TestProxy(var data: Test) : Test by data { init { val declaredFields = TestProxy::class.java.declaredFields val field: Field = declaredFields.find { it.name.contains("\$\$delegate") }!! field.isAccessible = true field.set(this, Proxy.newProxyInstance(TestProxy::class.java.classLoader, arrayOf(Test::class.java), { proxy, method, args -> method.invoke(data, *(args ?: arrayOf()))})) } } fun main(args: Array<String>) { val proxy = TestProxy(TestData("old")) println(proxy.name) proxy.data = TestData("new") println(proxy.name) } выводит: old new

Там на самом деле java.lang.reflect.Proxy не нужен. Я несколько переусложнил свой пример (изменение модификаторов у поля нужно только чтобы static final значение менять, для final достаточно setAccessible). Упрощённый вариант: fun main(args: Array<String>) { val proxy = TestProxy(TestData("old")) println(proxy.name) proxy.data = TestData("new") println(proxy.name) } interface Test { val name: String } class TestData(override val name: String) : Test class TestProxy(data: Test) : Test by data { var data: Test = data set(value) { delegateField.set(this, value) field = value } companion object { private val delegateField: Field by lazy { TestProxy::class.java.declaredFields .find { it.name.contains("\$\$delegate") }!! .apply { isAccessible = true } } } }

Там на самом деле java.lang.reflect.Proxy не нужен. Я несколько переусложнил свой пример (изменение модификаторов у поля нужно только чтобы static final значение менять, для final достаточно setAccessible). Упрощённый вариант: fun main(args: Array<String>) { val proxy = TestProxy(TestData("old")) println(proxy.name) proxy.data = TestData("new") println(proxy.name) } interface Test { val name: String } class TestData(override val name: String) : Test class TestProxy(data: Test) : Test by data { var data: Test = data set(value) { delegateField.set(this, value) field = value } companion object { private val delegateField: Field by lazy { TestProxy::class.java.declaredFields .find { it.name.contains("\$\$delegate") }!! .apply { isAccessible = true } } } }

да, я знаю

и там и там есть плюсы/минусы

А зачем data классы добавляют в класс componentN ?

А зачем data классы добавляют в класс componentN ?

https://kotlinlang.org/docs/reference/data-classes.html

А зачем data классы добавляют в класс componentN ?

для деструктурирования, вестимо

И какой номер issue в YouTrack?

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

для деструктурирования, вестимо

Вах, ясненько

классная штука

Но аргументов ждут от ТЕБЯ, можешь идти создавать issue

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

Каждый первый. По-моему сторонников не было

Собственно, обсуждение было избыточным.

Давайте что-то другое обсуждать

В смысле объема

Давайте что-то другое обсуждать

Я за! Нет времени читать сотни сообщений непонятно про что

Ради интереса. Как вам безаргументный main из Kotlin 1.3? (Считаете, что важно, пофиг или не понравилось) Немного схожа по идеологии фича с тем, что до этого обсуждали (loop в std-либе)

Ради интереса. Как вам безаргументный main из Kotlin 1.3? (Считаете, что важно, пофиг или не понравилось) Немного схожа по идеологии фича с тем, что до этого обсуждали (loop в std-либе)

Ну вот это нужно, так как очень частый кейс

В принципе да, но не совсем, тоже не освсем нужно, но область применения сильно шире

Плюс к тому, безаргументный main не получится написать в виде однострочной ФВП, а бесконечный цикл - легко.

Я за! Нет времени читать сотни сообщений непонятно про что

++++++

Щас компилировал проект, словил чего-то несусветное: e: java.lang.IllegalStateException: Backend Internal error: Exception during code generation Cause: Back-end (JVM) Internal error: wrong code generated org.jetbrains.kotlin.codegen.CompilationException Back-end (JVM) Internal error: Couldn't transform method node: calculateLU (Lscientifik/kmath/operations/Field;)Lkotlin/Pair;: и километр байткода. Надо наверное писать issue, но не знаю с какого конца начать

Щас компилировал проект, словил чего-то несусветное: e: java.lang.IllegalStateException: Backend Internal error: Exception during code generation Cause: Back-end (JVM) Internal error: wrong code generated org.jetbrains.kotlin.codegen.CompilationException Back-end (JVM) Internal error: Couldn't transform method node: calculateLU (Lscientifik/kmath/operations/Field;)Lkotlin/Pair;: и километр байткода. Надо наверное писать issue, но не знаю с какого конца начать

1. Разве ты не можешь подать репорт? 2. Согласен, issue

а как лучше Array<Long>? привести к Array<Long?>?

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

а как лучше Array<Long>? привести к Array<Long?>?

Лучше так не делать

а как лучше Array<Long>? привести к Array<Long?>?

array ?: emptyArray(), что ли?

а если мне надо?

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

а если мне надо?

непонятно, что именно надо

пофиг на боксинг

Если надо лучше сделать лист, но если совсем приспичит, то можно map{it as Long?}.toTypedArray()

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

Для нулябельных объектов массив делать не актуально. Все равно размещение на куче

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

val ARRAY_OF_NULL: Array<out Any?> = arrayOf(null) ... (arrayOfLongs ?: ARRAY_OF_NULL).forEach(::runMe)

другое поведение: if (arrayOfLongs.isNullOrEmpty()) runMe(null) else arrayOfLongs.forEach(::runMe)

val ARRAY_OF_NULL: Array<out Any?> = arrayOf(null) ... (arrayOfLongs ?: ARRAY_OF_NULL).forEach(::runMe)

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

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

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

пустого быть не должно

массива не будет

Мечтаю о хорошей книге по корутинам. О Structured concurrency, о паттернах, с конкретными примерами и с нескучным обсуждением всех загадочных параметров в конструкторах и тд итп

Так рано еще книги писать, тут еще не все устоялось.

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

а не, не фурычит

ок, нашел читаемый и работающий вариант

(places ?: arrayOfNulls<Long?>(1)).forEach({ })

меня смущает, что я не могу в переменную типа Array<Long?> положить Array<Long>

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

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

меня смущает, что я не могу в переменную типа Array<Long?> положить Array<Long>

в Array<out Long?> можешь

это магия как называется?

это магия как называется?

generic type variance

в Java — ? extends Long

т.е. Long наследуется от Long? ?

т.е. Long наследуется от Long? ?

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

ERROR: S client not available

А это работает? Массивы же вроде инвариантны. А почему именно масив, почему не список?

А это работает? Массивы же вроде инвариантны. А почему именно масив, почему не список?

Дженерики инвариантны. Массивы в джаве ковариантны.

В котилне инвариантны

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

а, ну да

> Note: unlike Java, arrays in Kotlin are invariant. This means that Kotlin does not let us assign an Array<String> to an Array<Any>, which prevents a possible runtime failure (but you can use Array<out Any>, see Type Projections).

но непонятно зачем

Зато List в Kotlin ковариантен

но непонятно зачем

чтобы не бросать ArrayStoreException?

ыменно

но непонятно зачем

Чтобы хранить что угодно

Там лонги

Зато List в Kotlin ковариантен

Потому что иммутабелен?

Потому что иммутабелен?

List ничего не гарантирует про иммутабельность

Потому что иммутабелен?

Именно так

ktor 1.0 alpha тегнули?

List ничего не гарантирует про иммутабельность

Ну методов изменения списка там нет

List ничего не гарантирует про иммутабельность

Гарантирует. List в Kotlin не содержит изменяющих методов

есть MutableList

А если говорить о рефлексии - то вообще никто ничего не гарантирует

есть MutableList

А он инвариантен

List при этом вполне может быть MutableList, который изменяет кто-то другой

это как val, который тоже не про иммутабельность

List при этом вполне может быть MutableList, который изменяет кто-то другой

Той части функционала, которая знает его как List это должно быть по барабану:)

Я вообще не про это. @Wizzardo хочет писать в массив 'Long?'. Не нонятно зачем. Списки для этого удобнее

Той части функционала, которая знает его как List это должно быть по барабану:)

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

List при этом вполне может быть MutableList, который изменяет кто-то другой

Ну тут идея в том, что так как использующий List может из него только читать, то можно List сделать ковариантным. Читатель - ковариант, так как потребитель супер типа может потреблять и тип. Писатель - контравариант, так как в роли производителя типа можно использовать производитель подтипа. Читатель + писатель - инвариант

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

Это должна понимать любая часть, работающая с данными, скрытыми на интерфейсом

это как val, который тоже не про иммутабельность

Вопрос где тогда она ?

Вопрос где тогда она ?

Ну это по коду смотреть надо :)

unmodifiableList(ArrayList(someList)) — вот она

Я вообще не про это. @Wizzardo хочет писать в массив 'Long?'. Не нонятно зачем. Списки для этого удобнее

мне в запросе приходит список айдишников, пофиг массив или лист, если параметра нет, то там null