Там же разработчики языка обсуждают дизайн. Как они решат - так и будет. И пока все сошлось на том, что точно будет, но детали в процессе

Текущие опаки вообще не ломают систему типов

Они внутри ломают гораздо меньше, чем вэлью классы

Там в обсуждениях были альтернативы с новым Top типом

Видел, да

Ну и обсуждение уже ушло дальше сипа

Проблема бойлерплейта стоит остро

Мне сложно понять, почему

Потому что 5 строк вместо одной - большой шаг назад. При этом в большинстве случаев нужно будет писать абсолютно одно и то же

Потому что 5 строк вместо одной - большой шаг назад. При этом в большинстве случаев нужно будет писать абсолютно одно и то же

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

Лучше несколько, но мощных

Энивалы часто используют как обертки над примитивами для сущностей из предметной области

У меня таких десятки, и я не хочу писать бойлерплейт

Энивалы часто используют как обертки над примитивами для сущностей из предметной области

Ну вот почему бы не использовать один энивал для кучи предметных обёрток?

ну точнее один опак

Как ты себе это представляешь? Я как раз таки хочу типами отличать разные вещи, у которых может быть под капотом одно и то же

Умел бы AnyVal копродукты

ну вот в шейплесе

есть конструктор ньютайпов

т.е. тебе нужен а-ля opaque type NewType[A, Ops] = A object NewType{ implicit def convertToOps[A, Ops](nt: NewType[A, Ops])(implicit conv: A => Ops): Ops = conv(nt) }

и потом type Weight = NewType[Double, WeightOps] implicit class WeightOps(val x: Double) extends AnyVal{ }

Пермишен на редактирование надо выставить.

точн, fixed

Вот есть у меня case class UserId(value: String) extends AnyVal case class Password(value: String) extends AnyVal Как такое сделать по твоему? И чтобы было так же лаконично

Вот есть у меня case class UserId(value: String) extends AnyVal case class Password(value: String) extends AnyVal Как такое сделать по твоему? И чтобы было так же лаконично

ну вот я кинул

В твоём случае, похоже даже Ops не нужно

Вот есть у меня case class UserId(value: String) extends AnyVal case class Password(value: String) extends AnyVal Как такое сделать по твоему? И чтобы было так же лаконично

а отчего не так ? type Password = String

а отчего не так ? type Password = String

можно тогда случайно передать UserID в место, которой хочет пароль

ну вот я кинул

А зачем каждому переизобретать в своей кодобазе тип Newtype, когда он нужен в подавляющем большинстве случаев?

А зачем каждому переизобретать в своей кодобазе тип Newtype, когда он нужен в подавляющем большинстве случаев?

не нужно

Вот есть у меня case class UserId(value: String) extends AnyVal case class Password(value: String) extends AnyVal Как такое сделать по твоему? И чтобы было так же лаконично

нафиг вам анивал тут

100% только хуже по перфу

будет одна либа какая-то, возможно supertagged 0.2

можно тогда случайно передать UserID в место, которой хочет пароль

а код def login( lg:Login, ps:Password) разве не проверит что ты не то пишешь ?

не проверит

а код def login( lg:Login, ps:Password) разве не проверит что ты не то пишешь ?

нет, ты же синоним объявил

в этом же и соль opaque

что они синонимы только в компаньоне

всё же shapeless/supertagged/etc это не то же что на уровне языка сделать, без лишних нагромождений

всё же shapeless/supertagged/etc это не то же что на уровне языка сделать, без лишних нагромождений

согласен

100% только хуже по перфу

Откуда инфа?

будет одна либа какая-то, возможно supertagged 0.2

Я надеюсь, что это будет в языке, а не в сторонней либе. Частые кейсы должны делаться легко и лаконично. Редкие должны быть возможны. С опаками не соблюдается первое правило.

https://failex.blogspot.com.by/2017/04/the-high-cost-of-anyval-subclasses.html

плотно сидим на extends TaggedType[RawType] (буквально все типы так делаем) - с радостью бы слезли на что-то встроенное

всё же shapeless/supertagged/etc это не то же что на уровне языка сделать, без лишних нагромождений

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

Я надеюсь, что это будет в языке, а не в сторонней либе. Частые кейсы должны делаться легко и лаконично. Редкие должны быть возможны. С опаками не соблюдается первое правило.

Ну вот надо понять, частый ли он

в хаскеле newtype же в языке, так почему нет?

100% только хуже по перфу

У нас не числодроьилка. Это больше для тайпсейфа

анивал каким боком то?

госпади

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

зачем тебе анивал там?

Чтобы не боксилось когда есть возможность, очевидно же

он чисто для "числодробилок"

ай

в хаскеле newtype же в языке, так почему нет?

ну вот opaque и есть newtype

просто в хашкеле в 95% случаев он совсем не для "обёрток для предментной области" юзается

а для чего?

тоже интересно

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

ну допустим, только как это отличается от "обёрток для предментной области"

У нас не числодроьилка. Это больше для тайпсейфа

Я конечно согласен, с тем что было бы клево иметь такие вещи встроенные в язык (при учете, что сделано будет красяво, а не то, что сейчас предлагается - там слегка ugly и кособоко выглядит)(хотя на самом деле мне больше нравится возможность симуляции средствами языка - так проще дойти до годных реализаций). Но у меня косвенный вопрос. В наших реалиях, когда есть таггет и ньютайпы в том виде в котором они сейчас - зачем все еще использовать AnyVal для которого мало того, что постоянно надо .value явно указать, чтобы значение получить так еще и при любом удобном случае в риал обертку сваливается(собственно в этом я вижу единственный плюс у энивала - возможность рантайм чека - правда не знаю, чтобы кто-нибудь этим пользовался) ?

анивал не нужен

(ц)

ну допустим, только как это отличается от "обёрток для предментной области"

Многие ньютайпы вообще не имеют публичных конструкторов

Это, конечно, не относится к обёрткам для инстансов

Я конечно согласен, с тем что было бы клево иметь такие вещи встроенные в язык (при учете, что сделано будет красяво, а не то, что сейчас предлагается - там слегка ugly и кособоко выглядит)(хотя на самом деле мне больше нравится возможность симуляции средствами языка - так проще дойти до годных реализаций). Но у меня косвенный вопрос. В наших реалиях, когда есть таггет и ньютайпы в том виде в котором они сейчас - зачем все еще использовать AnyVal для которого мало того, что постоянно надо .value явно указать, чтобы значение получить так еще и при любом удобном случае в риал обертку сваливается(собственно в этом я вижу единственный плюс у энивала - возможность рантайм чека - правда не знаю, чтобы кто-нибудь этим пользовался) ?

синтаксис

ERROR: S client not available

Я конечно согласен, с тем что было бы клево иметь такие вещи встроенные в язык (при учете, что сделано будет красяво, а не то, что сейчас предлагается - там слегка ugly и кособоко выглядит)(хотя на самом деле мне больше нравится возможность симуляции средствами языка - так проще дойти до годных реализаций). Но у меня косвенный вопрос. В наших реалиях, когда есть таггет и ньютайпы в том виде в котором они сейчас - зачем все еще использовать AnyVal для которого мало того, что постоянно надо .value явно указать, чтобы значение получить так еще и при любом удобном случае в риал обертку сваливается(собственно в этом я вижу единственный плюс у энивала - возможность рантайм чека - правда не знаю, чтобы кто-нибудь этим пользовался) ?

симуляциями средствами языка будет боксинг примитивов

симуляциями средствами языка будет боксинг примитивов

В текущих реалиях - да. Я же говорю про то, что мне больше импонирует. Сейчас есть проблема в том, что когда мы определяем type Newtype[Repr, Ops] = { type T = Tag[Repr, Ops] } - мы теряем информацию о типе в основании и при стирании эфемерных, компилятору не остается ничего другого кроме как использовать Object. Поэтому было бы достаточно каким-то образом добавить информацию об основании, которую бы компилятор смог использовать после стирания всего остального (какой-то флажочек мемори модел для эфемерных, который не попадает в скоуп, но оставляющий для компилятора свет в конце тоннеля). И в реализации это было бы проще, ведь все продолжило бы работать как и сейчас с тем отличием, что ушел бы боксинг. Но на 100% я не готов заявить, что это отличный выход - перед этим пришлось бы разобрать несколько возможных последствий сего флажка, но как-нибудь в другой раз)

В текущих реалиях - да. Я же говорю про то, что мне больше импонирует. Сейчас есть проблема в том, что когда мы определяем type Newtype[Repr, Ops] = { type T = Tag[Repr, Ops] } - мы теряем информацию о типе в основании и при стирании эфемерных, компилятору не остается ничего другого кроме как использовать Object. Поэтому было бы достаточно каким-то образом добавить информацию об основании, которую бы компилятор смог использовать после стирания всего остального (какой-то флажочек мемори модел для эфемерных, который не попадает в скоуп, но оставляющий для компилятора свет в конце тоннеля). И в реализации это было бы проще, ведь все продолжило бы работать как и сейчас с тем отличием, что ушел бы боксинг. Но на 100% я не готов заявить, что это отличный выход - перед этим пришлось бы разобрать несколько возможных последствий сего флажка, но как-нибудь в другой раз)

ну вот то, что ты описал и есть opaque

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

Они просто решили чутка наколдовать правильный тайпчек

В текущих реалиях - да. Я же говорю про то, что мне больше импонирует. Сейчас есть проблема в том, что когда мы определяем type Newtype[Repr, Ops] = { type T = Tag[Repr, Ops] } - мы теряем информацию о типе в основании и при стирании эфемерных, компилятору не остается ничего другого кроме как использовать Object. Поэтому было бы достаточно каким-то образом добавить информацию об основании, которую бы компилятор смог использовать после стирания всего остального (какой-то флажочек мемори модел для эфемерных, который не попадает в скоуп, но оставляющий для компилятора свет в конце тоннеля). И в реализации это было бы проще, ведь все продолжило бы работать как и сейчас с тем отличием, что ушел бы боксинг. Но на 100% я не готов заявить, что это отличный выход - перед этим пришлось бы разобрать несколько возможных последствий сего флажка, но как-нибудь в другой раз)

забудь про "стирания"

половина проблем в энивал от того что они пытаются "добавить информацию об основании"

Нет, 100% из-за того, что "они" пытаются сохранить семантику класса

тоже самое

тоже самое

Михаил под основанием имел в виду тип , который справа от равенства в opaque type Foo = Int

"добавить информацию об основании" = " сохранить семантику класса"

"добавить информацию об основании" = " сохранить семантику класса"

нет это вообще два не соотносящихся предложения

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

isInstanceOf

сохранить семантику класса - значит позволить матчить его, сравнивать по ссылке, вызывать this и т.п.

isInstanceOf

И что это?

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

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

Да это фактически противореяащие друг другу задачи

Потому говно и получилось

нет это одна и таже задача

нет это одна и таже задача

Нет разные

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

нет isInstanceOf - нет говна

А одном случае ты хочешь сохранить информацию, что это был Int

А в другом хочешь делать case x : Foo => чтобы работало

нет isInstanceOf - нет говна

не только его

У Object много методов

ну да

все это убрать и будет newtype

Потому и идея там пустить opaque type по альтернативной иерархии

все это убрать и будет newtype

Ну вот, но тогда это не может быть class

Поэтому value class и провалился