Я предлагаю не писать с нуля, а писать понятный, строгий код вместо рефлективного.

За все хорошее, против всего плохого! :)

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

За все хорошее, против всего плохого! :)

Вообще у нас даже production ready json mapper'a нету без рефлексии, так что несколько утопично движение в целом.

JSON хорош, пока он не покидает свою родную JS-экосистему.

Да что угодно что прилетает в jvm с наружи будет обладать примерно такими свойствами.

Protobuf, Cap'n'p, FlatBuffers? Нет.

JSON хорош, пока он не покидает свою родную JS-экосистему.

А можно взять swagger и нагенерить на клиенте модель/клиент и базовую авторизацию ?

Protobuf, Cap'n'p, FlatBuffers? Нет.

С точки зрения понятности происходящего они не чем не лучше. Просто магию отодвигают на компайл тайм

С точки зрения понятности происходящего они не чем не лучше. Просто магию отодвигают на компайл тайм

Вот этим и лучше. У тебя на руках код, который можно читать, тестировать, дебажить.

обычно генеренный код ты не очень хочешь читать, особенно того что будет там работать с байтиками разбирая bytebuffer

тестировать код который как-то рефлексивно работает тоже никто не мешает

дебажить проще, это да. и компайл тайм

но с таким же успехом можно написать компайл-тайм парсер для json, нет?

да, LoganSquare, ig-parser

О, интересно. Можно пример?

Фух, ели победил градл. Вот было: https://github.com/altavir/kplot/blob/82cea018f9cc444fd3700196e89af0f2020532b4/kplot-common/src/main/kotlin/scientifik/kplot/specifications/XYPlotSpecification.kt Вот стало: https://github.com/altavir/kplot/blob/master/kplot-common/src/main/kotlin/scientifik/kplot/specifications/XYPlotSpecification.kt Выглядит почти одинаково, но упрощение довольно существенное. Смысл в том, что есть неспециализированная конфигурационная структура, которую надо специализировать in place. Это делается навешиванием на нее декоратора, который занимается считыванием и изменением. В первом случае этот декоратор расширял класс конфигурации и просто делегировал все нужное передаваемому объекту. Во втором случае делается обертка, которая уже сама умеет делать нужные делегаты для своего содержимого.

Фух, ели победил градл. Вот было: https://github.com/altavir/kplot/blob/82cea018f9cc444fd3700196e89af0f2020532b4/kplot-common/src/main/kotlin/scientifik/kplot/specifications/XYPlotSpecification.kt Вот стало: https://github.com/altavir/kplot/blob/master/kplot-common/src/main/kotlin/scientifik/kplot/specifications/XYPlotSpecification.kt Выглядит почти одинаково, но упрощение довольно существенное. Смысл в том, что есть неспециализированная конфигурационная структура, которую надо специализировать in place. Это делается навешиванием на нее декоратора, который занимается считыванием и изменением. В первом случае этот декоратор расширял класс конфигурации и просто делегировал все нужное передаваемому объекту. Во втором случае делается обертка, которая уже сама умеет делать нужные делегаты для своего содержимого.

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

как победить котлин и gson + exclude Modifier.PRIVATE ? в котлине поле паблик, а все равно не попадает в json

в гугле не гуглится, надежд мало осталось перед погружением в сорцы

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

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

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

У тебя для внешнего пользователя только интерфейс поменялся с Configuration на Specification. Какая разница?

Довольно большая. Configuration - это сама конфигурация. Specification - это маркерный интерфейс для объекта, который содержит конфигурацию как компонент

Довольно большая. Configuration - это сама конфигурация. Specification - это маркерный интерфейс для объекта, который содержит конфигурацию как компонент

Я про то что какая разница, сам класс или делегат его реализует

Ты мог убрать делегат в первом случае, разве нет?

Тут никакой. Просто красивые. Делегаты убрать не мог потому что надо было бы всю реализацию писать. Этот интерфейс был

Поле != Проперти, добавь JVMField аннотацию

Поле != Проперти, добавь JVMField аннотацию

ага, я тупанул, спасибо (параллельно это нагулил тож)

Тут никакой. Просто красивые. Делегаты убрать не мог потому что надо было бы всю реализацию писать. Этот интерфейс был

Хотя делегировать функции, принимающей лямбду - это интересно

Надо придумать какой-нибудь dsl-трюк

Собственно я его и придумал. Теперь можно конфигурировать типо-безопасные объекты, используя спецификации: https://github.com/altavir/kplot/blob/master/kplot-examples/src/main/kotlin/scientifik/kplot/examples/JFreeChartFrameTest.kt. Единственная проблема, что хочется иметь две версии спецификации - мутабельную и немутабельную. Ноэто без кодогенерации видимо никак.

https://twitter.com/kotlinconf/status/1041683355937501185 Мне вот прям понравилась шутка из слака: "Kotlin is now an official language on iOS?"

Kotlin by default in Gradle!

(мечты)

Кто-нибудь может объяснить, зачем здесь <T>? public inline fun <T> Collection<T>.isNotEmpty() = !isEmpty()

Кто-нибудь может объяснить, зачем здесь <T>? public inline fun <T> Collection<T>.isNotEmpty() = !isEmpty()

нужно явно указывать тип, при использовании дженерика. То-есть просто Collection должно выдать ошибку, типа ты забыл кое-что указать (дженерик). Вроде так ?

Collection<*>

Collection<*>

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

ну да, так аккуратнее как-то

я думаю кому-то будет полезно https://www.youtube.com/watch?v=q_UM1EY2S5g

куантиум успокойся

куантиум успокойся

иди гуглить

я гуглил раз 75

тогда дебажить

мне надо на человеческом языке

тогда придётся проявить немного уважения к окружающим

я вроде никого не занижал

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

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

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

как бы андроид, не ? тогда что за framework

Последовательноти на котлине прямым образом наследуют стримы в яве, корнями уходят в дофункциональную эпоху. Для их понимания математика не нужна вообще.

Ууууу.... Не трогают они джавовых стримов

Насчёт того, что тут плохого: 1. Если про DI вообще, то он часто приводит к сильному смешению чистых вычислений и работы с состоянием, что приводит к невозможности проследить поток данных и управления. 2. Если про DI на процессинге аннотаций в рантайме, то дополнительно усложняется отслеживание того, кем, когда и как эти аннотации процессятся. 3. Если Spring like DI, то добавляются грабли с AutoWired и всякими неявными умолчаниями (подробно не помню, Spring боль была последний раз 3 года назад)

Бред какой...

воистину бред

Kotlin by default in Gradle!

> eriwen [01:11] > Heyo folks. You’ll be pleased to know that the vast majority of Groovy samples on in the Gradle user manual now have Kotlin samples too in the Gradle 5.0 nightly docs (https://docs.gradle.org/nightly/userguide/userguide.html) — please give them a look for your Kotlin DSL scripts and provide feedback via GitHub or hit us up on Slack! :D

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

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

А может кто-нибудь с градлом помочь?

У меня все проекты на мавене, когда-то пытался перекочевать на градл, но не вышло

я мог бы скинуть свой конфиг мавеновский для конверта

я мог бы скинуть свой конфиг мавеновский для конверта

?а это не смотрели случайно: https://guides.gradle.org/migrating-from-maven/

Думаю, смотрел, у меня там просто публикация + подписка gpg используются

ERROR: S client not available

+ укладывание всего этого счастья с зависимостями в один jar

У меня все проекты на мавене, когда-то пытался перекочевать на градл, но не вышло

Все не-android проекты*

Как следствие, я просто не понял, как аналогичный gradle конфиг сделать (хотя просто джарники билдились)

Так ты конкретные вопросы задавай, что не получается? Никто твои конфиги ковырять не будет

Так ты конкретные вопросы задавай, что не получается? Никто твои конфиги ковырять не будет

Пока не могу сказать - это не один месяц назад было:)

Ну вот как начнёшь миграцию снова, приходи ?

Ну вот как начнёшь миграцию снова, приходи ?

Ок?

Бред какой...

+ за самую обоснованную позицию

+ за самую обоснованную позицию

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

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

оххххх печево DI рабов

оххххх печево DI рабов

нет, под каждую задачу свои решения. если кто то не осилил, ну что же

оххххх печево DI рабов

Правильные ребята так и не научили жить без DI, пример большого проекта на Kotlin так никто не привел. Поэтому пока битва теоретиков с практиками)

Правильные ребята так и не научили жить без DI, пример большого проекта на Kotlin так никто не привел. Поэтому пока битва теоретиков с практиками)

+

Правильные ребята создают через конструкторы уже 3 десятка лет

а у них всё нет большого проекта

Но вообще что @lex_it @eld0727 давайте более конструктивно вести беседу. Без печева и бреда

Правильные ребята создают через конструкторы уже 3 десятка лет

а потом попробуй отладить и разобраться

Но вообще что @lex_it @eld0727 давайте более конструктивно вести беседу. Без печева и бреда

ок)

просто пост доставил)

а потом попробуй отладить и разобраться

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

а потом попробуй отладить и разобраться

А какие проблемы?

Вот есть код, он работает. Бери и разбирайся.

А какие проблемы?

в инициализации

потом это все поддерживать

править

то есть с отладкой всё же проблем нет.

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

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

А конструктивная критика будет? Или так и будет голову в песок и абстрактное: "вы не умеете готовить"?

А конструктивная критика будет? Или так и будет голову в песок и абстрактное: "вы не умеете готовить"?

читай, привожу

нет, под каждую задачу свои решения. если кто то не осилил, ну что же

Так можно любую позицию аргументировать: "Монадки не осилил, ну что поделать, все равно ФП рулит", "goto не осилил разобраться, ты просто не умеешь его правильно готовить"

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

А в чем проблема то?