Как можно передать CLI-аргументы в Kotlin-script из run configuration в IDEA?

Что есть cli аргументы?

Что есть cli аргументы?

Очевидно, то, что в обычном котлине приходит в main(...) параметром.

Что есть cli аргументы?

CLI — command-line interface. Например, если набрать в терминале java -jar app.jar -a b, то java достаются аргументы -jar app.jar -a b, а в main попадают -a b

Понял

Как можно передать CLI-аргументы в Kotlin-script из run configuration в IDEA?

А что, Program arguments - это не то?

нет

А что, Program arguments - это не то?

неа, они попадают в компилятор

https://leeks.life/Yj2SLr.png пример cli

вроде как

?

Речь о бекенде, фронте или фулл-стеке? Бекенд — ктор охренительно удобен. Фронт — советую проскакать какой-нибудь туториал про npm и react, а потом взять официальные котлиновские байндинги. Я с нуля vue.js разбирал без особого опыта в JS-ных фреймворках, он без особых проблем осваивается. Реакт — почти то же самое. только постарше и пофункциональнее. Ну и да, kotlin-frontend-plugin прячет бОльшую часть конфигурации этих ваших вебпаков, стандратного шаблона, который есть в примерах, достаточно. Фуллстек достигается путём двух гредл-модулей — один с kotlin-frontend-plugin + kotlin-platform-js, второй с kotlin-platform-jvm, после чего в processResources второго надо включить подтягивание собранных ресурсов первого.

А есть что нить для микросервисов? Типа discovery?

Вопрос про делегирование, есть такой код: interface I { fun f() } class A : I { override fun f() { println("A::f") } } class Registry { private val a = A() fun take(): A { return a } } class Delegate(registry: Registry) : I by registry.take() Что тут происходит: при создании класса Delegate вызывается registry.take() и возвращаемый объект в дальнейнем используется для делегирования. А можно ли сделать такой делегат, чтобы при вызове метода Delegate::f() объект A каждый раз брался из Registry::take() ?

Вопрос про делегирование, есть такой код: interface I { fun f() } class A : I { override fun f() { println("A::f") } } class Registry { private val a = A() fun take(): A { return a } } class Delegate(registry: Registry) : I by registry.take() Что тут происходит: при создании класса Delegate вызывается registry.take() и возвращаемый объект в дальнейнем используется для делегирования. А можно ли сделать такой делегат, чтобы при вызове метода Delegate::f() объект A каждый раз брался из Registry::take() ?

по-другому реализовать getValue

как именно?

как именно?

чтобы он каждый раз вызывал registry.take

непонятно тут же интерфейс делегируется, а не свойство можно примером кода пояснить?

я поясню зачем такое надо допустим у меня есть реестр, из которого я должен каждый раз доставать сервис I при использовании, потому что он может поменяться соответсвенно при вызове f() надо везде писать так registry.take().f() а хочется при помощи делегирования сделать враппер, который спрячет этот registry.take()

А есть что нить для микросервисов? Типа discovery?

Без идей, не задавался этим вопросом.

Без идей, не задавался этим вопросом.

А как же модные микросервисы пишете?)

А как же модные микросервисы пишете?)

Я — никак, я не бекендщик, а ктор ковыряю на досуге по фану.

непонятно тут же интерфейс делегируется, а не свойство можно примером кода пояснить?

сделать реализацию интерфейса, которая делегирует этот метод свежему инстансу

Я — никак, я не бекендщик, а ктор ковыряю на досуге по фану.

— - длинный дефис, отличительный признак фронтендщика, ну или людей, знакомых с их секретами

— - длинный дефис, отличительный признак фронтендщика, ну или людей, знакомых с их секретами

Тире — признак человека, который уважает русский язык.

Тире — признак человека, который уважает русский язык.

Согласен

сделать реализацию интерфейса, которая делегирует этот метод свежему инстансу

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

— - длинный дефис, отличительный признак фронтендщика, ну или людей, знакомых с их секретами

Я скипну наброс, если вы не против.

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

Сделать реализацию, которая вызывает каждый метод у свежей реализации. Можно подкостылить и использовать java.lang.reflect.Proxy.

Вопрос про делегирование, есть такой код: interface I { fun f() } class A : I { override fun f() { println("A::f") } } class Registry { private val a = A() fun take(): A { return a } } class Delegate(registry: Registry) : I by registry.take() Что тут происходит: при создании класса Delegate вызывается registry.take() и возвращаемый объект в дальнейнем используется для делегирования. А можно ли сделать такой делегат, чтобы при вызове метода Delegate::f() объект A каждый раз брался из Registry::take() ?

А какой сейчас класс генерируется?

А какой сейчас класс генерируется?

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

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

я ответил

я ответил

у меня сложилось впечатление, что либо мой вопрос был совсем не понят, либо я совсем не понял ответа

у меня сложилось впечатление, что либо мой вопрос был совсем не понят, либо я совсем не понял ответа

Тебе предложили на рантайме создавать proxy

Тебе предложили на рантайме создавать proxy

Через рефлекшн? Не, так не пойдет. Интересно есть ли compile time языковое решение.

Через рефлекшн? Не, так не пойдет. Интересно есть ли compile time языковое решение.

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

Через рефлекшн? Не, так не пойдет. Интересно есть ли compile time языковое решение.

Увы, если посмотреть через javap на вот такой вариант: class Delegate(var d: I): I by d:

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

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

public final class Delegate implements I { public final I getD(); Code: 0: aload_0 1: getfield #13 // Field d:LI; 4: areturn public final void setD(I); Code: 0: aload_1 1: ldc #19 // String <set-?> 3: invokestatic #25 // Method kotlin/jvm/internal/Intrinsics.checkParameterIsNotNull:(Ljava/lang/Object;Ljava/lang/String;)V 6: aload_0 7: aload_1 8: putfield #13 // Field d:LI; 11: return public Delegate(I); Code: 0: aload_1 1: ldc #27 // String d 3: invokestatic #25 // Method kotlin/jvm/internal/Intrinsics.checkParameterIsNotNull:(Ljava/lang/Object;Ljava/lang/String;)V 6: aload_0 7: invokespecial #30 // Method java/lang/Object."<init>":()V 10: aload_0 11: aload_1 12: putfield #33 // Field $$delegate_0:LI; 15: aload_0 16: aload_1 17: putfield #13 // Field d:LI; 20: return public void f(); Code: 0: aload_0 1: getfield #33 // Field $$delegate_0:LI; 4: invokeinterface #36, 1 // InterfaceMethod I.f:()V 9: return }

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

лямбде можно делегировать только реализацию SAM-интерфейса, т. к. она — один метод

работает с аттрибутом #33 тупо заданным в конструкторе

лямбде можно делегировать только реализацию SAM-интерфейса, т. к. она — один метод

Ну в данном случае в роли SAM выступает { registry.take() }

Ну в данном случае в роли SAM выступает { registry.take() }

у интерфейса есть единственный метод invoke, а у I, как ты говоришь, куча методов

у интерфейса есть единственный метод invoke, а у I, как ты говоришь, куча методов

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

работает с аттрибутом #33 тупо заданным в конструкторе

Печалька

да. это не —те дроиды— тот делегат, что вы ищете

ну а что если take() будет возвращать лямбду?

Жаль, а такая красивая идея была по выпиливанию лишнего кода. Хотя я где то уже слышал, что делегирование - это фича которые сами jetbrains считают не очень удачно сделанной.

Жаль, а такая красивая идея была по выпиливанию лишнего кода. Хотя я где то уже слышал, что делегирование - это фича которые сами jetbrains считают не очень удачно сделанной.

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

+ не так часто используется

+ не так часто используется

ну, проблема, наверное, не в этом)

+ не так часто используется

Хз, мне вот довольно часто бывает надо. В java в таких случаях приходилось руками писать.

... то получится чудовище, вроде d(Unit).f() которое синтаксически не приукрасить (вроде бы). Шило на мыло

ну а что если take() будет возвращать лямбду?

ну пока что оно не работает даже если take() возвращает просто ссылку предпочитаю решать проблемы по мере поступления )

d().f(), вот если бы еще оператор dot можно было переопределить ? но на такие извращения даже в крестах не решились

d().f(), вот если бы еще оператор dot можно было переопределить ? но на такие извращения даже в крестах не решились

Крестам достаточно возможности переопределить оператор разыменовывания и стрелку, ибо есть шанс написать my_obj-> и увидеть в саджешнах ТАКОЕ... (ШОК НЕ ДЛЯ СЛАБОНЕРВНЫХ СМОТРЕТЬ ВИДЕО БЕЗ РЕГИСТРАЦИИ НА ВЫСОКОЙ СКОРОСТИ)

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

Добрый день Бегло поискал ссылки на rx чатик, но не нашел Можно ли в RXJava (или RXKotlin) сделать штатными средствами следующее: На входе имеем данные, приходящие вразнобой во времени. Необходимо сделать так, чтобы onNext для подписчиков вызывался не чаще определенного времени. На данный момент решение выглядит так (далее код на Kotlin, но там нетрудно): val subject = PublishSubject.create<Int>() val timeSubject = Observable.interval(100L, TimeUnit.MILLISECONDS) val queue = ArrayDeque<Int>() subject.subscribe { queue.offer(it) } timeSubject.subscribe { if (queue.isNotEmpty()) { println("$it:${queue.pop()}")//Тут действие с сообщениями } }

И в общем-то всё хорошо и код рабочий, но RX я подключал не для того, чтобы такие велосипеды строить и хотелось бы понять - умеет ли rx что-то такое сам по себе? Если я правильно понял, существующий метод delay создаёт не задержку между сообщениями, а задержку между сообщением и доставкой сообщения подписчикам.

debounce оператор

debounce оператор

Он пропускает то, что приходит слишком часто

Не подходит

Погуглите список операторов полный

Он пропускает то, что приходит слишком часто

Он берет последний элемент за N времени

Вот поэтому он и не подходит

1 4 5 7 9 15 16 25 26 1 4 7 10 13 16 19 25 28 Сверху - время события от начала работы проги, Снизу - время уведомления обсервера от начала работы проги Интервал - 3

Он пропускает то, что приходит слишком часто

window / buffer вам в помощь.

Ребята, подскажите такой момент: есть метод, который возвращает пару текстовых полей + Лист с объектами. Данные объекты могут быть А, B, C, D, E типов. У данных типов есть несколько ОБЩИЙ полей(id, type), НО есть и уникальные для каждого типа поля. По TYPE можно понять, что это за тип. Использую retrofit. Для приема есть объект и в нём лист с базовым классом(у которого 2 поля id & type): class GetListResponse(success: Boolean, @Field("m_list") val list: List<BaseMyTypeResponse>) Предположим всё пришло и мы имеем лист базового типа объектов. Далее мне нужно: а) понять какой объект какого типа. Это делаем по полю type б) скастить данный объект в нужный тип. И вот тут вопросы: 1) данные типы(A, B, C, D) - должны быть просто data(ну как вариант)? Я стал создавать классы по типу базового, унаследованные от него, типа: class MyATypeResponse(id: String, type: String, uniq_filed:String: BaseMyTypeResponse(id, type) Но потом подумал, что это кажется не верный путь и нужно создавать уже именно data классы и в них кастить. Верно ли я думаю? 2) как лучше кастить в данном случае? Спасибо!

Ребята, подскажите такой момент: есть метод, который возвращает пару текстовых полей + Лист с объектами. Данные объекты могут быть А, B, C, D, E типов. У данных типов есть несколько ОБЩИЙ полей(id, type), НО есть и уникальные для каждого типа поля. По TYPE можно понять, что это за тип. Использую retrofit. Для приема есть объект и в нём лист с базовым классом(у которого 2 поля id & type): class GetListResponse(success: Boolean, @Field("m_list") val list: List<BaseMyTypeResponse>) Предположим всё пришло и мы имеем лист базового типа объектов. Далее мне нужно: а) понять какой объект какого типа. Это делаем по полю type б) скастить данный объект в нужный тип. И вот тут вопросы: 1) данные типы(A, B, C, D) - должны быть просто data(ну как вариант)? Я стал создавать классы по типу базового, унаследованные от него, типа: class MyATypeResponse(id: String, type: String, uniq_filed:String: BaseMyTypeResponse(id, type) Но потом подумал, что это кажется не верный путь и нужно создавать уже именно data классы и в них кастить. Верно ли я думаю? 2) как лучше кастить в данном случае? Спасибо!

data class нужен тогда, когда он нужен -- если нужны equals + hashCode, объекты будут деструктуризироваться и т.п. Подумайте, есть ли у вас такая необходимость. Если у вас есть пачка классов с одинаковыми полями и нужно кастоваться с учётом этого, логично предположить, что у вас есть иерархия типов с конечным количеством наследников. Это как раз то, о чём sealed классы. Опишите базовый тип с парой полей, наследников с остальными. Единственное -- для ретрофита надо написать конвертер, который решит проблему с парсингом JSON не в конкретный тип, а в один из его наследников в зависимости от содержимого. Но когда я последний раз смотрел, в сети были подсказки, как это сделать.

Есть такой код: async { while (true) { Log.d(TAG, "run") delay(300) } } Сначала пауза между "run" примерно 300 милисек. Но с течением времени работы програмы - эта пауза постоянно увеличивается (через 10 мин работы - пауза - 5 минут!) Почему так?

Есть такой код: async { while (true) { Log.d(TAG, "run") delay(300) } } Сначала пауза между "run" примерно 300 милисек. Но с течением времени работы програмы - эта пауза постоянно увеличивается (через 10 мин работы - пауза - 5 минут!) Почему так?

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

data class нужен тогда, когда он нужен -- если нужны equals + hashCode, объекты будут деструктуризироваться и т.п. Подумайте, есть ли у вас такая необходимость. Если у вас есть пачка классов с одинаковыми полями и нужно кастоваться с учётом этого, логично предположить, что у вас есть иерархия типов с конечным количеством наследников. Это как раз то, о чём sealed классы. Опишите базовый тип с парой полей, наследников с остальными. Единственное -- для ретрофита надо написать конвертер, который решит проблему с парсингом JSON не в конкретный тип, а в один из его наследников в зависимости от содержимого. Но когда я последний раз смотрел, в сети были подсказки, как это сделать.

Про sealed - спасибо, посмотрю. Про ретрофит - я вот потому и подумал - а обзятельно ли для ретрофита это делать(классы именно для него создавать) - или же хватит базового для ретрофита и, например, sealed классов для A, B, C, D. И в итоге базовый ретрофита - кастить в sealed class ATypeClass и т.д. Без конвертеров ретрофита Или так не выйдет?

Всем привет, есть довольно таки простой вопрос Как инициализиривать 2д массив рандомными значениями? Вот моя попытка var tab = IntArray(3, IntArray(3, {i->Random().nextInt(5).toInt()}))

Всем привет, есть довольно таки простой вопрос Как инициализиривать 2д массив рандомными значениями? Вот моя попытка var tab = IntArray(3, IntArray(3, {i->Random().nextInt(5).toInt()}))

Массив массивов — Array; IntArray — массив интов.

Почему так часто спрашивают про массивы? ?

Всем привет, есть довольно таки простой вопрос Как инициализиривать 2д массив рандомными значениями? Вот моя попытка var tab = IntArray(3, IntArray(3, {i->Random().nextInt(5).toInt()}))

val arr = Array(3) { IntArray(3) { Random().nextInt() } }

Почему так часто спрашивают про массивы? ?

Потому что их в реальном коде никто не использует, они нахер не нужны, поэтому их мало кто знает -)

Про sealed - спасибо, посмотрю. Про ретрофит - я вот потому и подумал - а обзятельно ли для ретрофита это делать(классы именно для него создавать) - или же хватит базового для ретрофита и, например, sealed классов для A, B, C, D. И в итоге базовый ретрофита - кастить в sealed class ATypeClass и т.д. Без конвертеров ретрофита Или так не выйдет?

Если у вас есть, положим, sealed class Request(val type: String) class MailRequest(type: String, receiver: String) , то ретрофиту в любом случае нужно понимать, что для "type": "mail" нужно будет создать именно MailRequest (собственно, Request — это абстрактый класс, его объект создать вообще нельзя). Так что без конвертера вряд ли удастся обойтись.

Ретрофит вообще этим не занимается.

Почему так часто спрашивают про массивы? ?

Ибо когда начинают втыкать в программирование - начинают втыкать в массивы и матрицы. И когда переходят на новый язык - как бы повторяют тот курс, который проходили с предыдущим языком. Я тоже когда только в котлин залез начал раскапывать про массивы и матрицы. :)

Спасибо большое

Массив массивов — Array; IntArray — массив интов.

val arr = Array(3) { IntArray(3) { Random().nextInt() } }

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

Ибо когда начинают втыкать в программирование - начинают втыкать в массивы и матрицы. И когда переходят на новый язык - как бы повторяют тот курс, который проходили с предыдущим языком. Я тоже когда только в котлин залез начал раскапывать про массивы и матрицы. :)

?

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

+

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

Ну типо если нужна нормальное распределение то да

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

?

А в чём проблема? Работа с числами, массивы, матрицы, связные списки, деревья, графы, стеки, очереди и т.п. - база.

не, к нормальному распределению в математическом смысле слова Random() вообще отношения не имеет

оно скорее равномерное

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

если нужен прям рандом рандомыч, то SecureRandom :)

А в чём проблема? Работа с числами, массивы, матрицы, связные списки, деревья, графы, стеки, очереди и т.п. - база.

Это байтоебская база, которая нахрен не уперлась в продуктовой разработке. Давно в проде линкед лист использовал? Я вот - ни разу.

Это байтоебская база, которая нахрен не уперлась в продуктовой разработке. Давно в проде линкед лист использовал? Я вот - ни разу.

Я, кстати, встречал линкедлисты в реальном коде. К сожалению.