Надо на android попробовать собрать

Меня вот всегда интересовало - кто все эти люди, которые голосуют в опросах, о которых я слышу только результаты??

общестенность давит ) задралло нервы тратить на объяснения )

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

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

А еще лучше настроить линтер чтобы сразу валил сборку и сам писал что не так

Меня вот всегда интересовало - кто все эти люди, которые голосуют в опросах, о которых я слышу только результаты??

Сам не знаю, как поучаствовать

А еще лучше настроить линтер чтобы сразу валил сборку и сам писал что не так

Не поможет. Придётся объяснять, почему линтер так настроен. Для этого и пишется гайдлайн с разъяснениями, чтобы самому каждый раз не объяснять одно и то же.

имеет ли смысл выделять однострочную строку тройными кавычками? часто вижу как иде предлагает переделать конкатинацию строк и переменных в строку с тройными кавычками и ${...}

сам обычно пользуюсь " и $

Не поможет. Придётся объяснять, почему линтер так настроен. Для этого и пишется гайдлайн с разъяснениями, чтобы самому каждый раз не объяснять одно и то же.

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

имеет ли смысл выделять однострочную строку тройными кавычками? часто вижу как иде предлагает переделать конкатинацию строк и переменных в строку с тройными кавычками и ${...}

прям предлагает?

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

Хм. Не знал. Спасибо за инфу

прям предлагает?

да

хотя наверно это из-за того что решили не читать есть ли в строке \n

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

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

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

если это так то это очень грустно

надо писать KEEP

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

пока

пока

Есть идеи, что с этим делать?

Я имею в виду с тем, что в Java-коде можно менять содержимое инлайн-класса

Я имею в виду с тем, что в Java-коде можно менять содержимое инлайн-класса

В джаве же вообще Object, причем тут конструктор

С этим ничего не сделать. Если боитесь что из Java кода кто-то будет менять, то не используейте inline classes.

Но вообще мы тут подстели соломки. Никакую фукнцию которая принимат паметр типа "inline class" нельзя вызвать из Java

С этим ничего не сделать. Если боитесь что из Java кода кто-то будет менять, то не используейте inline classes.

Ну то есть на это планируется забить и разрешить инициализатор?

Изначальный вопрос решается использованием энамов.

Не забить. Есть защита. От reflection, конечно, не защиться. Но на reflection забъем (с помощью него вообще много чего можно сломать)

Отлично!

inline class, судя по описанию, то же самое, что и newtype в Haskell. То есть просто способ на уровне системы типов различить оборачиваемое значение и обёрнутое. Зачем вам тогда фабричный метод для него? Чем просто использование конструктора не устраивает?

inline class, судя по описанию, то же самое, что и newtype в Haskell. То есть просто способ на уровне системы типов различить оборачиваемое значение и обёрнутое. Зачем вам тогда фабричный метод для него? Чем просто использование конструктора не устраивает?

тем что мы не можем сделать типа inline class String50CharacterLong

inline class, судя по описанию, то же самое, что и newtype в Haskell. То есть просто способ на уровне системы типов различить оборачиваемое значение и обёрнутое. Зачем вам тогда фабричный метод для него? Чем просто использование конструктора не устраивает?

В текущем виде конструктор фактически не может содержать кода

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

так бы был фабричный метод, возвращающий String50CharacterLong?

тем что мы не можем сделать типа inline class String50CharacterLong

Ну inline class для подобных ограничений и не предназначен.

как ето

почему нет?

по-моему, отличный юзкейс

или, например, inline class ValidSomething

Но делали-то его не под этот юз кейс

Это просто способ дописать свою реализацию для чего-то, что уже реализовано иначе в оборачиваемом типе. Вот хочется вам, чтобы для текстов length не учитывал пробельные символы и пунктуацию, но length для String уже работает иначе. Вы делаете inline class Text(val s: String) и реализуете свой length в нём

При этом, после компиляции, всё кроме length будет работать напрямую с обёрнутой строкой, и нет оверхеда на создание Text

https://kotlinlang.org/docs/reference/inline-classes.html Вот тут вроде всё очень подробно и с примерами описано. Написано, зачем нужно, как работает.

Это просто способ дописать свою реализацию для чего-то, что уже реализовано иначе в оборачиваемом типе. Вот хочется вам, чтобы для текстов length не учитывал пробельные символы и пунктуацию, но length для String уже работает иначе. Вы делаете inline class Text(val s: String) и реализуете свой length в нём

и не для этого, ящитаю

и не для этого, ящитаю

а для чего?

Это просто способ дописать свою реализацию для чего-то, что уже реализовано иначе в оборачиваемом типе. Вот хочется вам, чтобы для текстов length не учитывал пробельные символы и пунктуацию, но length для String уже работает иначе. Вы делаете inline class Text(val s: String) и реализуете свой length в нём

это то для чего оно используется в Haskell

и не для этого, ящитаю

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

а для чего?

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

это то для чего оно используется в Haskell

inline class по описанию полностью то же, что и newtype в Haskell.

избавиться от "dialogId: String, messageId: String, botId: String"

а для чего?

Чтобы представить существующий тип как вообще другой тип, безо всего его поведения. Например, обернуть ключи — в UserId, ClientId, ЛюбойДругойId завернуть UUID.

inline class по описанию полностью то же, что и newtype в Haskell.

но это не значит что его надо именно для этого использовать

или, чтобы количество методов в корутине сократить до одного ?

Чтобы представить существующий тип как вообще другой тип, безо всего его поведения. Например, обернуть ключи — в UserId, ClientId, ЛюбойДругойId завернуть UUID.

Зачем тогда не type alias, если вы не хотите по типам поведение развести?

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

Там всего пара примеров. «Дописывать» функциональность удобно экстеншенами, а инлайн-классами всё пробрасывать придётся.

Зачем тогда не type alias, если вы не хотите по типам поведение развести?

typealias тайпчекером игнорируется

Зачем тогда не type alias, если вы не хотите по типам поведение развести?

Чтобы не подсунуть чужой id

Там всего пара примеров. «Дописывать» функциональность удобно экстеншенами, а инлайн-классами всё пробрасывать придётся.

экстеншены затеняются родными методами

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

на самом деле они хороши для всех трех случаев

Чтобы не подсунуть чужой id

Значит у вас есть разное поведение для UserId, ClientId и прочего, которое вы по типам и разводите.

Значит у вас есть разное поведение для UserId, ClientId и прочего, которое вы по типам и разводите.

в этом есть рациональное зерно

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

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

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

так это и значит, что тебе есть разница, с каким id работать

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

ну смотри, value UserId дает id юзера, а ClientId - клиента

это, имхо, разное поведение

ERROR: S client not available

поведением обычно называют набор методов, интерфейс, а интерфейс как раз может быть абсолютно одинаковый, типа toUUID() ?

и возвращать они просто будет uuid, но вот спутать их в исопльзуемом коде уже будет невозможно

в отличии от тайпалиаса

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

поведением обычно называют набор методов, интерфейс, а интерфейс как раз может быть абсолютно одинаковый, типа toUUID() ?

то что методы называются одинкаово, еще не значит, что интерфейсы одинаковые, мы ведь не на питоне пишем?

поэтому оно и назыается поведением, а не интерфейсом в привычном понимании

да это спор о терминах

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

На примере разных Id: Есть у вас задача: доставать имя по Id. При этом для СlientId надо доставать из одного источника, для UserId из другого, но все они UUID. Если просто передавать UUID - не ясно, откуда брать имя. Если есть inline class - пишем val ClientId.name get() {...} val UserId.name get() {...} Вот у нас и реализовано разное поведение, в зависимости от типа Id

Без inline class тоже всё это можно, но будет оверхэд на создание обёрток.

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

На примере разных Id: Есть у вас задача: доставать имя по Id. При этом для СlientId надо доставать из одного источника, для UserId из другого, но все они UUID. Если просто передавать UUID - не ясно, откуда брать имя. Если есть inline class - пишем val ClientId.name get() {...} val UserId.name get() {...} Вот у нас и реализовано разное поведение, в зависимости от типа Id

Так сам id не знает имени. И нет гарантии, что для этого ID существует соответствующая запись.

Интересно, а если inline class оборачивает примитив, его можно сделать const val? ?

Интересно, а если inline class оборачивает примитив, его можно сделать const val? ?

и что это должно значить?

нельзя ?

и что это должно значить?

то же, что и с примитивами — «заинлайни меня, пожалуйста»

Так сам id не знает имени. И нет гарантии, что для этого ID существует соответствующая запись.

Да, сам Id не знает, но можно сделать интерфейс Named с абстрактным полем name и реализовать его в ClientId и UserId

Интересно, а если inline class оборачивает примитив, его можно сделать const val? ?

В аннотациях такие inline-классы тоже нельзя...

а rc версии грейдл-плагинов где лежат?

cline-овый грейдл чот странно как-то дружит с билд-файлами на котлине

точнее сказать, никак не дружит

а rc версии грейдл-плагинов где лежат?

они лежат в центральной репе плагинов

если что это андроид, но к сожалению там все молчат

а так кастить в байт массив легально вообще?

а так кастить в байт массив легально вообще?

о вот подсказали, что не легально

Какие есть гарантии что Array<Float> c оптимизируется в FloatArray ?

Какие есть гарантии что Array<Float> c оптимизируется в FloatArray ?

хм, кажется, что никаких

хм, кажется, что никаких

да проверил на простом примере(((

да проверил на простом примере(((

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

Да не умеет он так