Окей Тогда я ещё скажу своё решение, что на счёт него я

сделал минимальный билдер класс и теперь оно делается так
Payload { data("text"); metadata(byteArrayOf(1, 2, 3)) }
и тогда у data/metadata пару оверлоадов + можно достаточно просто это дело расширять под свои нужды
лучше это, или хуже 15 оверлоадов или BRP.fromString("text") и тд, что думаете?
учитывая, что это публичный апи либы

Если назвать это buildPayload, то очень даже норм. А там в теории может появиться что-то ещё?

да вот например там ещё compositeMetadata билдер https://github.com/rsocket/rsocket-kotlin/blob/enhancement/metadata-and-payload-api/playground/src/commonMain/kotlin/Metadata.kt#L41

вот кстати с buildPayload - это да, что-то я забыл про это

Так всё уже готово, в чём тогда вопрос? 😄

оно не готово ещё, в этом и суть, что хотелось бы узнать другие возможные варианты

DSL - беспроигрышный вариант в котлине. А этот BRP - это ваш класс или из джавовой либы?

из ktor-io)

Жаль, что в дслке нет возможности зафорсить наличие вызова конкретного метода, как обязательного data у вас, но в остальном это вполне логичное решение. В джаве, я думаю, я б такую задачу билдером и решал, аналогия вполне прямая в котлин получается.

в теории, data может быть пустой) поэтому указание только metadata - валидный кейс

Тогда я бы сделал конструктор с data и metadata, принимающими этот класс. Если что всегда можно накинуть ему в компаньон методы для создания из разных других типов.

А, ладно) Я по оригинальному посту подумал иначе.

Пустая data по дефолту - это сомнительное поведение. Если такое хочется, мне кажется, можно и явно указать.

я сейчас смотрю в сторону 2-ух ф-ий одна принимает 2 BRP вторая - билдер

может быть

Мне кажется, самое то 👍

оно просто имеет значение в малых кейсах единственное, не совсем валидный кейс наверно это Payload {} - но опять же, сомнительно, что кто-то такое будет делать

может быть и лучше падать сразу, по выходу из билдера, если нет explicit data, не знаю

Мне кажется, намного лучше. Чем быстрее упадёт код, который делает не то, что задумано, тем лучше. А иначе это какой-то protobuf style.

спасибо за фидбэк всем спасибо

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

В контрактах такое есть, но это скорее для ситуаций вроде val v: Int run { v = 42 } Но да, кто знает, может, докрутят :)

я видел это где-то в ветке котлина, либо в репозитории каком-то от JB то есть типа research :)

А, значит чёт другое)

нашёл! https://github.com/demiurg906/kotlin-contracts-samples/blob/master/src/main/kotlin/samples/SafeBuilders.kt

Симпатишно :) Там, похоже, ещё и механизм пропагации контрактов изнутри наружу прототипировался)

Ух, огнище, вот бы сделали такое

да там вообще много всего я так понимаю хотели на контрактах сделать А потом появились 3 компилятора, которые надо в один* объединить и походу весь ресёрч остановился надеюсь когда будет stable IR то начнётся жара

Все надеятся) Ладно, не все, но многие