Add tasty reflect members for definitions #4714
Conversation
| def TypeBoundsTreeDeco(bounds: TypeBoundsTree): TypeBoundsTreeAPI = new TypeBoundsTreeAPI { | ||
| def tpe(implicit ctx: Context): TypeBounds = bounds.tpe.asInstanceOf[Types.TypeBounds] | ||
| def low(implicit ctx: Context): TypeTree = bounds.asInstanceOf[tpd.TypeBoundsTree].lo | ||
| def hi(implicit ctx: Context): TypeTree = bounds.asInstanceOf[tpd.TypeBoundsTree].hi |
There was a problem hiding this comment.
asInstanceOf[tpd.TypeBoundsTree] is unnecessary. Same for the line before.
There was a problem hiding this comment.
TypeBoundsTree here is of type tpd.Tree but guaranteed to be tpd.TypeBoundsTree by the extractor, the cast is necessary.
There was a problem hiding this comment.
Ah, and this has all the usual dangers we've identified in our draft :-|... looking forward to a fix!
| val selfVal = if (self.isEmpty) None else Some(self) | ||
| Some((x.name.toString, constr, parents, selfVal, temp.body)) | ||
| val deco = ClassDefDeco(x) | ||
| Some((x.name.toString, deco.constructor, deco.parents, deco.self, deco.body)) |
There was a problem hiding this comment.
Calling ClassDefDeco seems to create unnecessary indirection here.
Another thought irrelevant to this PR but about the design: ClassDef and ClassDefDeco seem to have some duplication (that is why ClassDefDeco is called above). It seems possible to simplify the protocol between tasty API and concrete implementation such that extractors are implemented in the abstract API? Just a thought, no need to address in this PR.
There was a problem hiding this comment.
This was a simple way to reduce code duplication. I'm considering extending the ClassDefAPI to make it the result of the extractor (with name-based pattern matching). This way there will be only one instantiation and maybe the contents can be lazily extracted.
We can access members of
With this addition we can also do
optionallyfor optional trees