Changes to signatures?

[Simon Ochsenreither]

Hi Brian,
 
sorry for my late reply.
 
> Its possible this will be stuffed into the signature
> attribute, and also possible we'll add another attribute instead. This
> is effectively a "syntax" decision that can be late-bound (if in your
> capacity as compiler-maintainer, you have an opinion, feel free to share.)
 
I think it really depends on the expressivity of the various signatures. As far
as I currently see it, the BytecodeMapping attribute tries to encode the bare
minimum, which might be easier to support in different compilers than Generic
Signatures.
 
Generic Signatures are kind of "optional" currently and aren't really checked
for consistency, and scalac doesn't really try too hard to emit sensible
sigantures, because most intersting things can't be expressed in Java anyway. So
any change to that status quo would certainly have a (likely negative) impact.

> It's a good time to revisit the generics-related attributes in the class
> file; one thing that has been a persistent source of pain, that we might
> fix now, is to have an attribute that encodes metadata about *all* the
> type variables from enclosing lexical scopes, rather than having to go
> to N different class files to gather that. (The status quo is OK for
> compilers, which have probably pulled in the classes anyway, but less OK
> for a runtime specializer.) The specializer needs this since to
> transform TT; to something, it has to know what T is being specialized
> to, and that means it has to know all the tvars in scope, not just the
> ones declared in the current class/method.
 
This sounds like a reasonable concern. The only thing I'm worried about is that
it might even further increase the time until tools like ASM (and therefore
other languages) might support this, increasing the delay of implementation and
feedback from implementors.
 
Thanks and bye,
 
Simon