Это понятно. Но c.Expr[Any] deprecated вроде как

а зачем тебе Expr?

просто Tree

просто Tree

Возвращать Tree?

ну нет

возвращать какой-то типа trait Container{ type Result def result: Result }и в макросах подставлять туда type Result = String или type Result = Option[String]

соответственно возвращать можно Tree

или Expr[Container]

Вот такая гора интерсует - как сделать тип возвращаемого выражения зависимым от входящего выражения? Ну, условно, имеем на входе String «1» - вернем String, String «2» - Option[String] и т.д.

def foo[T](x: T): T = macro fooImpl[T] def fooImpl[T: WeakTypeTag](c: Context)(x: c.Tree): c.Tree = ...

или я не правильно понял?

похоже да. невнимательно прочитал вопрос

def foo[T](x: T): T = macro fooImpl[T] def fooImpl[T: WeakTypeTag](c: Context)(x: c.Tree): c.Tree = ...

Нет, не так

def foo[T](x: T): T = macro fooImpl[T] def fooImpl[T: WeakTypeTag](c: Context)(x: c.Tree): c.Tree = ...

так можно, только это не скомпилится

WeakTypeTag - это type member c

поэтому либо явно имплисит параметром, либо bundle

class A[T] { def foo(x: String) = macro fooImpl[T] }

вот такое хочу

так можно, только это не скомпилится

не занудствуй. я всегда макрокомпатом пользуюсь.

class A[T] { def foo(x: String) = macro fooImpl[T] }

ок

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

def foo(x: String): Container = macro fooImpl

class A[T] { def foo(x: String) = macro fooImpl[T] }

T здесь - это не тип возвращаемого значения, а тип, с объявлениями которого работаем в макро

да мы поняли

def foo(x: String): Container = macro fooImpl

Так. А с контейнером этим потом как дальше жить?

Хотя кажется до меня начинает доходить

короче, если хочешь вычислять типы в компайл-тайме, тебе нужно сложить их в качестве контейнера

и не смотря на то, что тип твой объявлен как Container

компилятор в случае вайтбокса в конкретном слуае вычислит тип как Container{type Result = Option[String]}

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

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

ок, спасибо

т.е. если ты вызовешь foo("2").result компилятор сможет догнать, что это Option[String] а не какая-то стёртая фигня

но если у тебя не настоящие компайл-тайм вычисления

а просто если-то

то проще сделать имплиситами

т.е. если ты вызовешь foo("2").result компилятор сможет догнать, что это Option[String] а не какая-то стёртая фигня

так, а если без .result - можно как-то?

с Aux и всей это фигнёй

так, а если без .result - можно как-то?

нет, обязательно нужна обёртка, которую ты можешь уточнить в whitebox

Поэтому например, у шейплеса есть Witness

Просто обёртка, в которую складывается довычисленный тип

так, а если без .result - можно как-то?

можешь сделать макро-материализацию

ааа нет, не можешь

вообще в большинстве случаев то, что ты хочешь сделать с константами своим макросом можно заменить на Witness.Lt

и дальше оперировать только типами

вообще в большинстве случаев то, что ты хочешь сделать с константами своим макросом можно заменить на Witness.Lt

Попробую копнуть туда. Спасибо!

Ребят, здравствуйте. Помогите с Type Erasure. Суть проблемы: хочется уйти от создания 100500 case class'ov, для моего трейта в котором, есть поле: Any, и от этого трейта еще наследование идет. Набросал пример: https://scalafiddle.io/sf/QPC44f6/0 Читал тут, https://medium.com/@sinisalouc/overcoming-type-erasure-in-scala-8f2422070d20 Мне вообще нормально подходит ClassTag, но что-то не получилось с ним нормально матчинг сделать. Ах да. Суть. Сделать матчинг по типу case x:AwesomeCaseClass[Int] => case x:AwesomeCaseClass[String] =>

Что-то вроде asInstanceOf не сработает?

Ребят, здравствуйте. Помогите с Type Erasure. Суть проблемы: хочется уйти от создания 100500 case class'ov, для моего трейта в котором, есть поле: Any, и от этого трейта еще наследование идет. Набросал пример: https://scalafiddle.io/sf/QPC44f6/0 Читал тут, https://medium.com/@sinisalouc/overcoming-type-erasure-in-scala-8f2422070d20 Мне вообще нормально подходит ClassTag, но что-то не получилось с ним нормально матчинг сделать. Ах да. Суть. Сделать матчинг по типу case x:AwesomeCaseClass[Int] => case x:AwesomeCaseClass[String] =>

Ты же можешь матчить тип твоего value shit match { case x@AwesomeCaseClass(_, _, _: Int) => case x@AwesomeCaseClass(_, _, _: String) => }

ну это все неприкольно, мне кажется, нормальные ребята так не матчят

да в fiddle, я привожу, что такой матчинг работает

ну это все неприкольно, мне кажется, нормальные ребята так не матчят

Так матчи так, шоб это работало и читалось, а не было рокет сайенсом ?

ну это все неприкольно, мне кажется, нормальные ребята так не матчят

Прикольные ребята, которым нужен такой полиморфизм, могут сделать для каждого кейса тайп класс

Но кажется оно тебе не надо

Ребят, здравствуйте. Помогите с Type Erasure. Суть проблемы: хочется уйти от создания 100500 case class'ov, для моего трейта в котором, есть поле: Any, и от этого трейта еще наследование идет. Набросал пример: https://scalafiddle.io/sf/QPC44f6/0 Читал тут, https://medium.com/@sinisalouc/overcoming-type-erasure-in-scala-8f2422070d20 Мне вообще нормально подходит ClassTag, но что-то не получилось с ним нормально матчинг сделать. Ах да. Суть. Сделать матчинг по типу case x:AwesomeCaseClass[Int] => case x:AwesomeCaseClass[String] =>

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

Any только для того, чтобы можно было обощить, и использовать конструкции типа val someField: List[HasValue[_]] ну если грубо.. а так типы то известны, просто делать на каждый тип свой кейс класс, как-то не комфильфо) в общем, у меня проблемы..

есть две дочерних класса, отличаются одним полем и вот для одного делать 10 кейс-классов из-за типов value, для второго еще 10 итого 20 классов втф(((((((((( хочется, чтобы был 1 абстрактный или трейт и всего 2 дочерних, уже нормальных кейсовых

(((((((((((((((((

Попробую копнуть туда. Спасибо!

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

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

Да. Я хотел это прикрутить к Dynamic, там на этапе компиляции всё известно должно быть

Да. Я хотел это прикрутить к Dynamic, там на этапе компиляции всё известно должно быть

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

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

Скорее в академических целях - натянуть Dynamic на стандартные сгенерированные protoc java-классы, чтобы поддержать Option[T] для optional и сохранить типобезопасность

В общем, странного хотел :)

В общем, странного хотел :)

да уж. очень странного. проще имплисит опс javaOptional.toOption )

да уж. очень странного. проще имплисит опс javaOptional.toOption )

неее. там это не так работает

неее. там это не так работает

можешь пример с ява классом и использованием этой фичи накидать в пару строк?

if (message.hasFieldName()) Some(message.getFieldName()) else None

хочу - DynamicMessage(message).field_name

(условно)

ERROR: S client not available

хочу - DynamicMessage(message).field_name

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

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

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

бойлерплейт спилить. Когда у тебя 5 вложенных мессаджей и ты пытаешься использовать java обертку - вот эти все has-get очень утомляют

бойлерплейт спилить. Когда у тебя 5 вложенных мессаджей и ты пытаешься использовать java обертку - вот эти все has-get очень утомляют

зачем самому использовать hasFieldName() ? это какая-то динамическая мапа? если нет, то зачем этот метод тебе вобще вызывать?

зачем самому использовать hasFieldName() ? это какая-то динамическая мапа? если нет, то зачем этот метод тебе вобще вызывать?

Так. Ты работал с протобафом раньше? :)

Так. Ты работал с протобафом раньше? :)

нет, но ты можешь ткнуть в какой-нибудь тутор с ява кодом где показана эта боль с hasFieldName() )

protoc из файлика типа message BarFoo { optional string foo_bar = 1; } сгенерит что-то типа на Java class BarFoo { boolean hasFooBar() { ??? } String getFooBar() { ??? } }

Попытка обратиться к getFooBar если hasFooBar == false обернется эксепшеном

Попытка обратиться к getFooBar если hasFooBar == false обернется эксепшеном

на самом деле вернет дефолтное значение

@fellrond я не могу понять, какую проблему ты решаешь?

@fellrond посмотри вот это https://github.com/limansky/beanpuree - если не подойдет, как минимум там примеры макрсов для геттер/сеттер чепухи есть

@fellrond я не могу понять, какую проблему ты решаешь?

Академический интерес, говорю же :)

на самом деле вернет дефолтное значение

Ну, да. Для optional Message это будет null :)

Ну, да. Для optional Message это будет null :)

а что в нем плохого? Option(null) и вперед)

а что в нем плохого? Option(null) и вперед)

Option(msg.getFoo()).flatMap(f => Option(f.getBar)).flatMap(b => Option(b.getZzz()).flatMap…

Хочу DynamicMessage(msg).foo.bar.zzz возвращающий Option[zzz.type]

нету там нулов в протобафе

открой нагенеренный класс

для опшена там None

дефолт

открой нагенеренный класс

Кстати да, с какой-то версии не null. DefaultInstance

Ещё хуже :)

lastSent: scala.Option[com.google.protobuf.timestamp.Timestamp] = None,

lastSent: scala.Option[com.google.protobuf.timestamp.Timestamp] = None,

Это у тебя scala-pb небось?

fuf

ага

ну дык

я про protoc-java

а

тогда есть

:D

Хочу DynamicMessage(msg).foo.bar.zzz возвращающий Option[zzz.type]

вот. наконец то дошли до реальной боли) однако, давай продолжим. DynamicMessage(msg).foo - должен вернуть Option[Foo] или DynamicMessage[Foo] ?