AN
Просто const было бы вполне достаточно
Не совсем. data - это про контракт на добавочные методы, а конст - на иммутабельность
Size: a a a
2020 February 25
BV
Не совсем. data - это про контракт на добавочные методы, а конст - на иммутабельность
Ну да 🤷♂
BV
И я о том же
AN
Ну да 🤷♂
Ну я могу себе представить конст без даты и дату без конста. В общем хочу
2020 February 26
K
это нормально объявлять пустой companion object, чтобы навесить позже на него extension?
AM
это нормально объявлять пустой companion object, чтобы навесить позже на него extension?
Да.
BP
это нормально объявлять пустой companion object, чтобы навесить позже на него extension?
Даже был тред что бы компилятор автоматом генерил компаньёнов (вроде для енумов только)
AN
Даже был тред что бы компилятор автоматом генерил компаньёнов (вроде для енумов только)
Ишью весит. Можно найти и залайкать.
D𝔇
Хочу const data class
а чем это будет отличаться от data с val'ами?
AN
а чем это будет отличаться от data с val'ами?
Гарантией того, что все внутри тоже const. И как следствие оптимизациями
K
Даже был тред что бы компилятор автоматом генерил компаньёнов (вроде для енумов только)
я помню тот тикет, там вроде еще было про генерить автоматом для java классов. Просто оно как-то одиноко смотрится, если это руками делать, кто-то может пройти и удалить еще, потому что пустой же. Но раз чатик говорит, что норм, то хорошо!) Спасибо.
T
Гарантией того, что все внутри тоже const. И как следствие оптимизациями
+ Для функциональщины очень годно.
AN
+ Для функциональщины очень годно.
Да и без нее
RE
Даже был тред что бы компилятор автоматом генерил компаньёнов (вроде для енумов только)
Это не та проблема, которая заслуживает решения. Решать надо другую проблему — как повесить "расширение" на класс, автор которого не задекларировал компаньон. И дело не только в Java классах, но и в Kotlin классах без компаньонов.
AN
Это не та проблема, которая заслуживает решения. Решать надо другую проблему — как повесить "расширение" на класс, автор которого не задекларировал компаньон. И дело не только в Java классах, но и в Kotlin классах без компаньонов.
А в чем отличие от того, что Богдан сказал? Если нет компаньена, то его или что-то его заменяющее было бы хорошо генерировать.
SB
Это не та проблема, которая заслуживает решения. Решать надо другую проблему — как повесить "расширение" на класс, автор которого не задекларировал компаньон. И дело не только в Java классах, но и в Kotlin классах без компаньонов.
Вызов будет выглядеть как статик метод?
RE
А в чем отличие от того, что Богдан сказал? Если нет компаньена, то его или что-то его заменяющее было бы хорошо генерировать.
"Геренировать компаньон" или "вешать на класс без компаньона" это совсем разные вещи. У компаньона есть identity. Зачем его заводить, если он не нужен для той или иной задачи?
AN
"Геренировать компаньон" или "вешать на класс без компаньона" это совсем разные вещи. У компаньона есть identity. Зачем его заводить, если он не нужен для той или иной задачи?
А, ну тут спору нет. Генерировать компаньен не обязательно совершенно. Достаточно, чтобы синтаксически оно работало
AO
"Геренировать компаньон" или "вешать на класс без компаньона" это совсем разные вещи. У компаньона есть identity. Зачем его заводить, если он не нужен для той или иной задачи?
Чтобы не плодить сущности, получается будет функция с ресивером и какая то особая функция для класса
AN
Чтобы не плодить сущности, получается будет функция с ресивером и какая то особая функция для класса
так он же обжект, какая разница?