Кто-нибудь вкурсе

value

классы работают в Exposed?

Если реализовать соответствующий

ColumnType

для

value class

, то у вас все будет работать.

Спасибо. Подумаю стоит ли свичаться со Спринг даты на Exposed :)

А что вы хотите от value классов?

У меня есть доменная айдишка, которая сама по себе просто строка. По сути эти Value Object. Вот, хочу ее в таком же виде и хранить в базе, без всяких трансформаций. Спринг дата не поддерживает value классы.

Ну в принципе да, просто для строки value класс особенно много чего не даст. В exposed нет рефлексии, так что должно работать

То как мне объяснили, что такое в джаве инлайн классы, мне казалось, что это как раз то, что мне нужно. Придать какой-то строке доменный смысл.

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

Согласен. В целом это был просто повод попробовать инлайн классы. Я уже ревертнул все обратно и сделал просто тайпалиас, хотя и в этом смысла не много. Хотелось, просто сделать красиво, по-доменному.)

Value-класс - это метод оптимизации, у него нет (пока по крайней мере) отдельного семантического смысла.

Я понимаю, с точки зрения языка - да.

Смысл в том, что вы и так можете завернуть эту строку в класс, не делая к нему модификатор value

Можно, да. Но тогда либо иметь геттеры, либо туСтринг переписать.

А value-класс вас от этого не спасет

А можно что-нибудь почитать, что лучше объяснить суть инлайн классов в джаве? Я так-то с пхп мира пришёл, до этого ни строчки на джаве, и уж тем более на котлине, не писал.

Повторюсь, на данный момент это просто оптимизация для оберточных классов, которые оборачивают ровно одно поле.

В котлине или вообще в джаве?

Вы совершенно спокойно написать

class MyId(val string: String)

и использовать его.

А. Понятно. Теперь я вижу как мои вопросы звучат слегка нелепо.)

Да нет, это очень частый вопрос. Просто value - классы часто пихают там, где без них можно отлично обойтись, а проблемы от них есть все равно. Это чисто оптимизационная фича

Понял. Спасибо! Да, я действительно хотел его пихнуть скорее чтоб пихнуть, чем от необходимости. Понимание было совсем другое.)

спокойно написать class MyId(val string: String)

@altavir А equals/hashCode/toString тоже спокойно руками написать?

Ну, можно немного и понервничать же тоже?

@ilya.gorbunov для value класса они довольно непредксазуемо работают

Непредсказуемо — в смысле не хватает документации того, как они генерируются?

Вот грабли, на которые я сам наступал: интерфейс, его наследуют два класса, один из них инлайн/value. Как будет работать сравнение? Ответ, оно будет работать странно. Сравнение для value классов - это вообще опасная дорожка, потому что они по идее могут сравниваться только структурно, а значит по хорошему только сами с собой. Hashcode в основном используется для ключей в картах, но использовать value классы как ключи (пока) не особенно осмысленно, потому что они мгновенно теряют всю свою оптимизационную суть.

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

А разве сгенерированный equals как раз не такой? Первым же делом идет проверка что второй инстанс ровно того же value-типа

Я к тому, что он получается не симметричный. Если один наследник value класс, а второй - нет, то получается труба

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

Я знаю. Просто мы много где пытались по делу воткнуть инлайн классы и мест, где это реально помогает получается очень мало (а багов с ними много). При этом желающих воткнуть их ради того, чтобы воткнуть, очень много. Поэтому я не говорю, что их не надо использовать, но рекомендую руководствоваться принципом "если вы не знаете, нужно оно вам или нет, значит не нужно".

TL;DR, лучше использовать

data class

одного поля.

Ну вот пока да. При всей моей любви к концепции value-классов