Кто-нибудь вкурсе `value` классы работают в <Expos...
# russian
a
Кто-нибудь вкурсе
value
классы работают в Exposed?
i
Если реализовать соответствующий
ColumnType
для
value class
, то у вас все будет работать.
a
Спасибо. Подумаю стоит ли свичаться со Спринг даты на Exposed :)
a
А что вы хотите от value классов?
a
У меня есть доменная айдишка, которая сама по себе просто строка. По сути эти Value Object. Вот, хочу ее в таком же виде и хранить в базе, без всяких трансформаций. Спринг дата не поддерживает value классы.
В целом, я джавой/котлином занимаюсь всего пол года, поэтому может я чего не так делаю/чего-то не так понимаю.
a
Ну в принципе да, просто для строки value класс особенно много чего не даст. В exposed нет рефлексии, так что должно работать
a
То как мне объяснили, что такое в джаве инлайн классы, мне казалось, что это как раз то, что мне нужно. Придать какой-то строке доменный смысл.
a
Это нужно для того, чтобы сэкономить на оверхеде при завертывании строки в другой класс. Для строки этот оверхед очень маленький и если у вас не три миллиона таких строк, то не факт, что это нужно
a
Согласен. В целом это был просто повод попробовать инлайн классы. Я уже ревертнул все обратно и сделал просто тайпалиас, хотя и в этом смысла не много. Хотелось, просто сделать красиво, по-доменному.)
a
Value-класс - это метод оптимизации, у него нет (пока по крайней мере) отдельного семантического смысла.
a
Я понимаю, с точки зрения языка - да.
С точки зрения просто структуры кода - вполне, мне кажется. Строка получает какое-то конкретное предназначение.)
a
Смысл в том, что вы и так можете завернуть эту строку в класс, не делая к нему модификатор value
a
Можно, да. Но тогда либо иметь геттеры, либо туСтринг переписать.
a
А value-класс вас от этого не спасет
a
А можно что-нибудь почитать, что лучше объяснить суть инлайн классов в джаве? Я так-то с пхп мира пришёл, до этого ни строчки на джаве, и уж тем более на котлине, не писал.
a
Повторюсь, на данный момент это просто оптимизация для оберточных классов, которые оборачивают ровно одно поле.
a
В котлине или вообще в джаве?
a
Вы совершенно спокойно написать
Copy code
class MyId(val string: String)
и использовать его.
В джаве нет пока инлайн классов и не известно, когда будут
a
А. Понятно. Теперь я вижу как мои вопросы звучат слегка нелепо.)
a
Да нет, это очень частый вопрос. Просто value - классы часто пихают там, где без них можно отлично обойтись, а проблемы от них есть все равно. Это чисто оптимизационная фича
a
Понял. Спасибо! Да, я действительно хотел его пихнуть скорее чтоб пихнуть, чем от необходимости. Понимание было совсем другое.)
i
спокойно написать class MyId(val string: String)
@altavir А equals/hashCode/toString тоже спокойно руками написать?
a
Ну, можно немного и понервничать же тоже?
a
@ilya.gorbunov для value класса они довольно непредксазуемо работают
i
Непредсказуемо — в смысле не хватает документации того, как они генерируются?
a
Вот грабли, на которые я сам наступал: интерфейс, его наследуют два класса, один из них инлайн/value. Как будет работать сравнение? Ответ, оно будет работать странно. Сравнение для value классов - это вообще опасная дорожка, потому что они по идее могут сравниваться только структурно, а значит по хорошему только сами с собой. Hashcode в основном используется для ключей в картах, но использовать value классы как ключи (пока) не особенно осмысленно, потому что они мгновенно теряют всю свою оптимизационную суть.
i
потому что они по идее могут сравниваться только структурно, а значит по хорошему только сами с собой.
А разве сгенерированный equals как раз не такой? Первым же делом идет проверка что второй инстанс ровно того же value-типа
a
Я к тому, что он получается не симметричный. Если один наследник value класс, а второй - нет, то получается труба
i
Пока есть ограничение, что equals нельзя переопределить, например в случаях, когда нужно чтобы разные наследники были сравнимы между собой, но в будущем это ограничение может быть снято.
a
Я знаю. Просто мы много где пытались по делу воткнуть инлайн классы и мест, где это реально помогает получается очень мало (а багов с ними много). При этом желающих воткнуть их ради того, чтобы воткнуть, очень много. Поэтому я не говорю, что их не надо использовать, но рекомендую руководствоваться принципом "если вы не знаете, нужно оно вам или нет, значит не нужно".
i
TL;DR, лучше использовать
data class
одного поля.
a
Ну вот пока да. При всей моей любви к концепции value-классов