Ok, I'll gives us all a world see what happens.  I'm curious to see if it's 
backward compatible if we simply omit the types.
Ter
On Feb 15, 2010, at 1:47 AM, Kay Röpke wrote:

> Hi!
> 
> On Feb 15, 2010, at 1:07 AM, Terence Parr wrote:
> 
>> Ok, thanks Kay (and George in a private thread). it sounds to me like we 
>> only really need to specify the AST type (which can default to object when 
>> we don't care...hmm...can Java do that?) and token type. token type is fine 
>> as an interface; no point in parameterizing, unless there's some 
>> optimization that the compiler will find when we use more concrete types but 
>> it seems to work okay now
> 
> 
> There's no optimization at all, no. All it does is to add type safety, type 
> erasure makes generic types look the same at runtime (or to use my favorite 
> obfuscation from the manuals: Parameterized types are not covariant :)).
> If we don't need them, that's fine. Alternatively one could use a bounded 
> wildcard type for the payload, e.g. <? extends Token>, but I'm not sure we 
> really need to over plain Token. We'll see, it's easier to check it out once 
> the code is working anyway.
> 
> I don't think we need to default to Object at all, since someone needs to 
> specify the ASTLabelType anyway (hetero trees might still need casts in 
> actions, though, but not for the generated and runtime code, since we won't 
> care about their special methods/fields at that level, only that the 
> corresponding tree adaptor can handle the node types).
> Again, maybe using ASTLabelType = <? extends BaseTree> could work as a 
> default, as long as we only call methods declared in BaseTree on them (and 
> let the tree adaptor handle the rest).
> I'd have to see actual code before deciding though, generics overwhelm my 
> brain and I'm severely under-caffeinated :)
> 
> cheers,
> -k
> 
> -- 
> Kay Röpke
> 

_______________________________________________
antlr-dev mailing list
[email protected]
http://www.antlr.org/mailman/listinfo/antlr-dev

Reply via email to