У нас разное понимание семантики

https://t.me/scala_ru/272698 вот здесь ты дописываешь результирующий тип в метод, это был нерелевантный аргумент

На этом закроем срач

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

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

точнее там и дискуссиии то вначале не было, просто Апач как попугай заладил, что надо избегать перегрузки - а почему - так и не сказал

Да, я хотел уточнить в названиях разных create из чего они создают акторсистему, это непосредственно относится к самому исходному коду, где некоторый объект мог создаваться разными способами https://t.me/scala_ru/272529

я разве писал, что "перегрузка лучше всегда" ? ))

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

ну вот опять давай берем этот конкретный уже код. чем это лучше?
`def fromServiceModel(v: A):C = from(c.bigDecimal)
def fromBigDecimal(v:BigDecimal):C = ...
`

чем
`def from(v:A):C = from(c.bigDecimal)
def from(v:BigDecimal):C = ...
`

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

нет, такого посыла (что перегрузка всегда лучше) я никогда не отстаивал)

А можно поподробнее про проседание  производительности при исопльзовании AnyVal, мне казалось, что это как раз способ уменьшить оверхед на новый тип?

ну я вот потыкал сейчас, чтобы потом к котовому ИО перейти мне нужно апкаст оптику к Exception все равно сделать,  я верно понял?

как будто в вопросе подразумевается ответ - да эти буквы не бесполезны, например
map(fromServiceModel) будет лучше, чем
map(CumulativeCoefficient.from(_ : ServiceModel))

только в том случае, если AnyVal вырежется компилятором - что на практике означает не так уж много случаев. Во всех остальных это полный экивалент class MyWrapper(value:String) - физическая обертка-пустышка со всеми вытекающими.

эм. но второй случай должен выглядеть проще  map(CumulativeCoefficient.from) (в мап у нас уже приходит ServiceModel) . К тому же в первом случае придется еще и импорт ручками писать, потому что идея не умеет импортить методы автоматом. Ну и опять таки, если у меня в мапу на вход вдруг станет приходить bigdecimal - для второго случая мне не придется ничего менять. для первого придется менять 2 места - импорт + вызов.

Вот жи, элементарно. Не знаю зачем в этих конкретных случаях писать def fromInt и получать сплошные неудобства)

хм, я как раз ловил проблемы, что в рантайме AnyVal был не отличим от типа над которым была обертка.

Ну и собственно из доки: Properly-defined user value classes provide a way to improve performance on user-defined types by avoiding object allocation at runtime, and by replacing virtual method invocations with static method invocations.

Ну и там перечислены когда это выполняется:

User-defined value classes which avoid object allocation...
 *  must have a single val parameter that is the underlying runtime representation.
 *  can define defs, but no vals, vars, or nested traitss, classes or objects.
 *  typically extend no other trait apart from AnyVal.
 *  cannot be used in type tests or pattern matching.
 *  may not override equals or hashCode methods.

но это странный кейс, когда обертка над AnyVal содержит еще какие-то значений.

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

я как раз ловил проблемы, что в рантайме AnyVal был не отличим от типа над которым была обертка. - это не проблема, это то как он должен себя везти. А вместо этого он на каждый чих скатывается в свои ограничения. А точнее в пункт про cannot be used in type tests

Ну и плюс бесконечные мусорные  myval.value - чтобы достучаться до самого значения. Когда код усыпан этим - прям буэээ. А теги дают гарантию отсутствия обертки + могут быть использованы напрямую в качестве основания (а если нужно исключить это - ньютайпы - и опять с гарантией отсутствия оберток (правда обьективизация все же будет - примитивы перейдут в обьектные эквиваленты (только для ньютайпов, в тегах так же примитивы)))