首页 文章

后代类中的宏扩展

提问于
浏览 次
3

我有下一个类结构：

trait SomeType

trait Root {
  val allMySomeTypes: Seq[SomeType]
}

class Child extends Root {
  object MyType1 extends SomeType {...}
  object MyType2 extends SomeType {...}
}

我想初始化val allMySomeTypes作为扩展在具体类中定义的SomeType的所有对象的Seq . 所以对于Child实例，它将是val allMySomeTypes：Seq [SomeType] = Seq（MyType1，MyType2） .

我写了一个宏来查找具有一些基类型的对象：

def getMembersOfCurrentByType_impl[S](c: Context)(implicit ev: c.WeakTypeTag[S]) = {
  import c.universe._
  val seqApply = Select(reify(Seq).tree, newTermName("apply"))
  val objs = c.enclosingClass.symbol.typeSignature.declarations.collect {
    case o: ModuleSymbol if o.typeSignature <:< ev.tpe => Ident(o) //Select(c.prefix.tree, o)
  }.toList
  c.Expr[Seq[S]] {Apply(seqApply, objs)}
}

并绑定到

trait Root {
  val allMySomeTypes: Seq[SomeType] = macro getMembersOfCurrentByType_impl[SomeType]
}

但是，显然，由于基本特征的宏扩展，我在Child类中有空序列 . 我可以在没有在Child类中额外输入而不使用运行时反射的情况下构建实际成员的Seq吗？

scala scala-macros

1 回答

  • 5

    General case of subclass detection

    有趣的是，我们刚刚在几天前讨论了在一般情况下列出给定类的所有子类的可能性 . 这是我当时发布的答案：

    目前不可能枚举任意类的所有子类，但我们确实有一个名为 ClassSymbol.knownDirectSubclasses 的API，它枚举了密封的后代 .

    但不幸的是，即便这样也不容易 . knownDirectSubclasses API在人们以某种方式使用它的意义上或多或少都很好，但它也有一个严重的缺陷，我们目前不知道如何修复：https://groups.google.com/forum/#!topic/scala-internals/LRfKffsPxVA .

    Particular case of subclass detection

    但是，这个StackOverflow问题会询问更具体的内容 . 我们如何将自己局限于某个类的成员，那么是否有可能选择那些我们感兴趣的类的子类？

    好吧，事实证明，尽管目前有一个API来处理（ c.enclosingClass 族的 c.enclosingTree 方法），但即使是这个特殊情况仍然无法稳健地处理 .

    问题是Scala宏在类型检查期间被扩展，这意味着在给定宏被扩展时，它的封闭树被强调了 . "being typechecked"状态意味着某些封闭的树可能暂时处于不一致的状态's going to break down if one tries to inspect them. There'在Scala Macro Annotations: c.TypeCheck of annotated type causes StackOverflowError进行了更详细的讨论，但在这里我只举一个简单的例子 .

    例如，如果您的宏在具有未指定返回类型的方法内扩展（例如 def foo = yourMacro(1, 2, 3) ），则调用 c.enclosingDef.symbol.typeSignature 将导致宏扩展失败，因为要知道方法的签名，您需要推断其返回类型，但要推断你需要扩展宏的返回类型，你需要知道方法的签名等 . 顺便说一句，编译器足够智能，以便不在这里无限循环 - 它将打破循环早期并显示循环参考错误 .

    这意味着要很好地处理非局部宏扩展，我们需要对类型签名及其依赖关系进行某种声明性抽象，而不仅仅是命令式的 typeSignature 方法 . 我想出了一些令人满意的东西，这也是为什么在Scala 2.11中我们要弃用非本地 c.enclosingTree 方法的原因之一：https://github.com/scala/scala/pull/3354 .

    随着宏观注释的出现，这个主题将变得更加重要，所以我们还没有承认失败 . 我认为，期待这一领域取得进展是合理的，但我们没有具体的日期可以提供给这一领域 .

    A possible workaround

    正如我上面提到的，我们在检测子类的任务中遇到的“唯一”问题是它是一个与执行它的宏扩展相关的非本地操作 . 那么我们如何将其转变为本地运营呢？事实证明这是可能的 .

    通过在 Child 类上放置宏注释，在宏中，您可能会导致潜在的虚假循环错误 .

    但是，如果这些成员不必从成员本身获取这些类型 . 我们可以使用带注释的类，复制它，对其进行检查，然后检查类型检查的结果，而不必担心会破坏被注意者 . 以下是为实施此策略提供灵感的示例：Can't access Parent's Members while dealing with Macro Annotations .

    tl;dr

    • 目前，由于理论和实施原因，宏观扩张期间的非本地业务可能很难或不可能强有力地执行 . SI-7046就是一个例子，这个问题提供了另一个例子 .

    • 有时可以通过在宏观中包含更大的范围来重新定义非本地宏观扩张问题作为本地宏观扩张问题 . 宏天堂插件提供的宏注释可能有助于此目的 .

    回复于

相关问题