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

Мутабельный lateinit - не православно как кто ?

лейтинит не мжет быть имутабельным)

Ибо lateinit нужно использовать только для di в классах фреймворка,где нельзя через конструктор инжектить

лейтинит не мжет быть имутабельным)

может, просто пользуйтесь Kotlin-M13

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

и на каждую вьюшку по классу делегату создавать)

https://blog.jetbrains.com/kotlin/2015/09/kotlin-m13-is-out/

Android extension - typesafe из коробки

class Example { @Inject lateinit val foo: Foo @Inject lateinit var bar: Bar } хорошо же было)

да. было бы круто

а почему выпилили?

лейтинит не мжет быть имутабельным)

Тем более ? (смысл был что мутабельный, а ещё и lateinit который не поверишь, в отличие от T?)

в M14 написано

Тем более ? (смысл был что мутабельный, а ещё и lateinit который не поверишь, в отличие от T?)

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

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

И падать с исключениями...

с каким?)

дайте ссылку где все это читать?

то что касается андроида

то что касается андроида

medium.com

с каким?)

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

а вот T? ты еще и не сразу догадаешься почему у тебя что-то не работает

ну это касательно андроид вьюх

а вот T? ты еще и не сразу догадаешься почему у тебя что-то не работает

Ну лично я за val. В случае с findById можно хоть сделать val view by lazy { find... }

Ну лично я за val. В случае с findById можно хоть сделать val view by lazy { find... }

здесь тоже может упасть

если вызвать до setContentView в активити например

а с фрагментами как быть?)

если вызвать до setContentView в активити например

Логично

а с фрагментами как быть?)

хотя там можно что-нибудь придумать, но оно имхо того не стоит

@HeapyHop добавь что ли в описание чата, а то они так и будут... (страдать фигнёй, ведь ⭐️ этого чата все равно не догнать ?)

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

вообще поиском по "stats" находится моментально

Android extension,если речь идёт про активити/фрагменты/вьюхи

по поводу андроид экстеншенов. Я про них слышал, но не трогал (да как и контлин то в общем). Я правльно понимаю что это просто набор экстеншн функций для activity и fragment. Которые впринципе можно и самому написать...?

вообще поиском по "stats" находится моментально

Спасибо

по поводу андроид экстеншенов. Я про них слышал, но не трогал (да как и контлин то в общем). Я правльно понимаю что это просто набор экстеншн функций для activity и fragment. Которые впринципе можно и самому написать...?

нет. это просто примочка с помощью которой можно не иницилизировать вьюхи вообще

по поводу андроид экстеншенов. Я про них слышал, но не трогал (да как и контлин то в общем). Я правльно понимаю что это просто набор экстеншн функций для activity и fragment. Которые впринципе можно и самому написать...?

Врятли ты это сам напишешь. Там ещё какая-то компиляторная магия с анализом xml и генерацией кода.

Врятли ты это сам напишешь. Там ещё какая-то компиляторная магия с анализом xml и генерацией кода.

понял спасибо.

не робит чет балалайка(анко превью).?

не робит чет балалайка(анко превью).?

Оно давно не работает стабильно уже

Сегодня смотрел байт код который генерится для when и не осилил понять что за гавно там генерится

По факту вытягивается условие в филд на стеке

Все ок

Потом if(var2){ ....} else { if(var2){ throw WhenBlaBlaBlaException() } ... }

И тут как бы вопрос

Нахрена в ветке для false ещё раз проверять это же условие

Ладно это был бы филд класса

Но это переменная вытянутая из when(...)

Если у кого есть идеи буду рад услышать

Ну и если надо могу показать кодом на гисте

Что лучше использовать в Kotlin - sealed class или enum class в качестве перечисления? Насколько я знаю, использование Enum в Android не то что бы нежелательно, но вносит некоторое дополнительное количество методов в конечную сборку.

Что лучше использовать в Kotlin - sealed class или enum class в качестве перечисления? Насколько я знаю, использование Enum в Android не то что бы нежелательно, но вносит некоторое дополнительное количество методов в конечную сборку.

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

вообще если нужно чисто енумы то да enum class. sealed когда что-то вроде adt

если вам нужно просто перечисление типо AccountType { User,Bot } то енам

если вам нужно филды хранить внутри

то sealed class

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

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

может конечно я чего то не знаю

вообще почти всегда можно написать более идеоматиченый код с sealed class'ами

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

Нет. Енумы решаемая проблема. От них можно просто отказаться

Что лучше использовать в Kotlin - sealed class или enum class в качестве перечисления? Насколько я знаю, использование Enum в Android не то что бы нежелательно, но вносит некоторое дополнительное количество методов в конечную сборку.

sealed внесёт ещё больше ;)

ну и там не в методах, а в размере объектов в памяти

+ не занимайтесь преждевременной оптимизацией, в большинстве случаев вы не заметите разницы при использовании IntDef. Оно может быть заметным только в очень незначительном числе кейсов

ERROR: S client not available

Нет. Енумы решаемая проблема. От них можно просто отказаться

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

извиняюсь за оффтоп в котлин чате)

Мне чисто была интересна внутрення реализация. С использованием Kotlin Bytecode из Android Studio 3.0 я её увидел.

Буду использовать Enum :)

Kotlin Bytecode есть и до 3.0

Опа, сюрприз. Первый раз увидел на I/O 2017

Только что посмотрел - и правда есть

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

ты их серьёзно так используешь? тип если нужен синглтон пишешь енум с одним кейзом?

Я тоже их так серьёзно использую.

а если в котлине объявить топлевел val то он тоже потокобезопасный синглтон?

Нет, тут дело именно в java enum class.

а вот допустим джава. делаешь класс с приватным конструктором и полем public static final ну и там вызываешь этот приватный конструктор. это будет тот самый потокобезопасный синглтон?

Это на полном серьёзе вопрос или я чувствую некую издёвку?)

хз. ну я бывает туговат

В таком случае - нет, это не потокобезопасный синглтон. Помимо синхронизации при создании объекта есть ещё синхронизация при обращении к данным.

ну идея такая: обычно синглтоны обладают некоторым lazy свойством. в енумах его вроде бы и нет. всё статично появляется. ну и я думаю у енума в этом плане есть альтернативы

ты их серьёзно так используешь? тип если нужен синглтон пишешь енум с одним кейзом?

нет, но...почему бы и нет?

ого. вот это скрытый потенциал у енума.

а ну и да,забыл упомянуть,что если вы юзаете enum как филд вашего data class'а у вас гавнокод :D

Почему?

а ну и да,забыл упомянуть,что если вы юзаете enum как филд вашего data class'а у вас гавнокод :D

да, кстати, почему?

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

а можете просто сделать sealed классы для каждого типа

с нужными филдами

вы понимаете, когда лучше использовать sealed, а когда enum? или вы всегда sealed?

sealed class Expr data class Const(val number: Double) : Expr() data class Sum(val e1: Expr, val e2: Expr) : Expr() object NotANumber : Expr() здесь в примере используются разные конструкторы, разное количество полей. вообще здесь не целесообразно использовать enum

enum class Direction { NORTH, SOUTH, WEST, EAST } зачем здесь sealed?

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

и тогда это реально дерьмо