Ну в шарпах приватки с аксесорами начинаются с "_"

вообще придерживаюсь этого https://github.com/ribot/android-guidelines/blob/master/project_and_code_guidelines.md

надеюсь только на java

Видел такое в котлете где-то

надеюсь только на java

конешно

Видел такое в котлете где-то

где?

где?

Для backing field только вроде

хоть и выглядит неконсистентно

https://kotlinlang.org/docs/reference/properties.html#backing-properties

Да

Backing field

Backing property. С точки зрения языка у backing field нет имени.

Copy?

это разные классы

в один маппится прямо из БД, в другой — уже после разрешения связей

А что смущает?

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

ЭТО НОРМА во всякой функциональщине

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

а что если возвращать что-то вроде Pair<LessonTree, List<TaskTree>>, так как в новые объекты добавляется только lesson

а что если возвращать что-то вроде Pair<LessonTree, List<TaskTree>>, так как в новые объекты добавляется только lesson

я мапплю это в такую структуру, которую мне удобно отдать в шаблонизатор

ну ладно

не очень хочется в шаблоне писать ${pair.first....}

Кстати, кто пробовал DSL для HTML? Годно как шаблонизатор?

Кто-нибудь пробовал двинуться дальше и сделать DSL для CSS? :)

Кто-нибудь пробовал двинуться дальше и сделать DSL для CSS? :)

Я пытался, но вышло не очень. Руки из жопа.) Есть либа, названия к сожалению не помню.

Я пытался, но вышло не очень. Руки из жопа.) Есть либа, названия к сожалению не помню.

Меня просто привлекает идея избавиться от шаблонизаторов, котрые ломают статический анализ и рассматривают объекты как мапки.

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

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

хотя может это и не страшно

У тебя какая-то бета idea или котлина? У меня типы не пишет для exp-functions.

У тебя какая-то бета idea или котлина? У меня типы не пишет для exp-functions.

да, 2017.3 EAP

Понятно, лучш буду типы ставить ?

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

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

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

> в грейдле придумали делегаты использовать О чём это? Не уловил.

Меня просто привлекает идея избавиться от шаблонизаторов, котрые ломают статический анализ и рассматривают объекты как мапки.

https://github.com/olegcherr/Aza-Kotlin-CSS

https://github.com/olegcherr/Aza-Kotlin-CSS

класс, спасибо!

> в грейдле придумали делегаты использовать О чём это? Не уловил.

Делегат знает своё имя, поэтому можно написать val test by delegateFactory() и имя test будет доступно в рантайме

Делегат знает своё имя, поэтому можно написать val test by delegateFactory() и имя test будет доступно в рантайме

а, понял

кто-то имел практику изучения Kotlin in action с хреновым инглишем? без замороченных языковых (англ) конструкций книга?

она легко читается

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

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

ну короче легко читается энивей

Окай

а кто как екстеншен функции группирует

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

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

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

там всё довольно коротко и внятно описано и минимальное прктическое применение этого всего можно коанами получить

а кто как екстеншен функции группирует

по смыслу

ну тоесть как раньше в джаве утильные классы собирали

в старые добрые времена

а кто как екстеншен функции группирует

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

если utils.kt разрастается, то выношу оттуда по смыслу, вот на днях вынес все методы для работы с Path например

Субпакет util, там файлы-агрегаторы экстеншенов по смыслу

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

ну я тоже также делаю. значит все ок) спасибо

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

и всё равно пишешь эти экстеншены

Надо написать скрипт (или плагин) который из произвольных JavaUtils классов - генерит Kotlin-Extensions

Нет, надо джава интероп улучшить.

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

Это ж так и устроено в экстеншенах

Да лан, тебе что мало ? val path = Path(“”) path.let(::delete) .let(::deleteIfExists) …

А передача аргументов?

Лет уже не подходит

А ведь если бы так сделали сразу, то не пришлось бы в стандартной библиотеке тонны экстеншенов дублировать из всяких StringUtils

В общем, недосмотр

В общем, недосмотр

Ага и на любом double или int мне бы выплевывалось куча методов из java.lang.Math и еще кучи несвязанных либ - спасибо не надо

Требуется более умное поведение подсказчика )

Сейчас же тоже есть проблема с засорением пространства экстеншенами

В скале это решается импортом только нужных имплиситов

Ну так мы не скале ? и нет тут имплиситов, только ext-functions Вообщем не надо тащить в язык, то что можно сделать по другому и так же удобно.

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

(утил класса)

Было бы неплохо найти серебряную пулю в подходе и запилить такое.

Исплиситы и на скале рекомендуется юзать только когда вариантов других нет :)

Смотря какие

Всякие Rich-обертки, Ops - это в постоянном обиходе

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

Вот это будет очень странно

Если все джавовые методы превратяться в экстеншены, да и в джаве не всегда первый параметр есть this

Можно конечно придумать специальный XML... Но зачем если можно просто написать в нужном месте свой экстеншен?

Если все джавовые методы превратяться в экстеншены, да и в джаве не всегда первый параметр есть this

Только статики, и не все, а только если утилити класс заимпортировать специальным вариантом импорта. Надо придумать такой )

import StringUtils.* as extensions Типа такого

Много линуксоидов из котлинистов?