[antlr-interest] Duplicate members when generating code with 2 import levels in Java with ANTLR-3.1.1

[Terence Parr]

On Oct 28, 2008, at 1:42 PM, Loring Craymer wrote:

>>   isn't that overloading rather than overwriting? nothing to do with
>> object-oriented programming if I remember correctly.
>
> Overwriting?

overriding...voice recog error.

>>> As you mention, interpretation depends on the message sent, and part
>>> of the message are the data type expectations.
>>
>> but unless you are using ML and so on,  most languages are not
>> polymorphic on the argument types or the return signatures.
>
> Actually, modern languages are, although the polymorphism is  
> static.  Consider the usual Java examples
> toString()
> toString(int indent)
> ...
>
> Java supports argument polymorphism, but not return type polymorphism;

that's overloading not polymorphism bro.

foo(X x) {;}
foo(Y y) {;}

Object o = ...;
foo(o);

which does it execute?  Java says "huh?" and polym. calls would at  
runtime do the right dispatch.

>>> On another note, ANTLR lacks the data abstractions that go with the
>>> OO idea of inheritance.  The mechanism implemented in ANTLR 3 looks
>>> much more like Python's module import facility than it does
>>> inheritance.
>>
>> Can you give an example of what you can't do with antlr's grammar
>> composition that you could do with an ordinary object oriented
>> language?  *the* quintessential example of polymorphism is the one I
>> gave where you inherit method that calls a method overridden in the
>> subclass. If your language doesn't do that, it's not polymorphic.  
>> what
>> you're talking about is something totally different: parameter-based
>> polymorphism or simple overloading as you describe above.
>
> Unless I am very much mistaken, composed grammars do not incorporate  
> action code from subgrammars, other than that embedded in  
> productions.  That is, data and behavioral semantics from  
> subgrammars are not inherited and thus the OO paradigm is violated.   
> Productions are also not polymorphic, as discussed above.

Actions?  You mean fields?  that's not necessary for polymorphism.

> I repeat:  as implemented, grammar composition is almost identical  
> to Python's module imports and does not fit the OO inheritance model  
> except by a long stretch of the imagination.

We're talking polymorphism of rules.  Inheritance is an include minus  
polymorphism and the type eqiv stuff.

Ter