Hi Doug:

>From dougo@ccs.neu.edu Wed Oct  8 07:42:27 1997
>From: Doug Orleans <dougo@ccs.neu.edu>
>To: jayantha@ccs.neu.edu
>cc: dem@ccs.neu.edu
>Subject: parsing an abstract class
>
>Josh: A while ago, you were asking why there was no "parse" method for
>an abstract class; the reason is that its return value would be
>different from the return values of the "parse" methods on its
>concrete descendants, which is illegal in Java.  However, you can
>still parse an abstract class if you want; just call:
>
>    new Parser(inputStream)._Foo()
>
>where "inputStream" is an instance of java.io.InputStream, and "Foo"
>is the name of the abstract class you want to parse.  The return type
>will be "Foo".
>
>Karl: should we document this?  i.e. make official the convention that

Yes, this should be mentioned in the User's Guide. I put it in the directory:
"To go into  User's Guide" off
http://www.ccs.neu.edu/research/demeter/DemeterJava/use/
for now.

>"_" + <classname> is the name of the parser function for parsing
><classname>?  It's also currently used in lookahead specifications.
>An alternative would be to put the classname in the name of the static
>parsing methods on each class, e.g. "parse_Foo" instead of "parse".
>This seems a little redundant, though, since you'd have to say
>"Foo.parse_Foo()".  Maybe we could only do this for abstract methods,
>but then the naming convention is not consistent.  Yet another
>alternative is to get rid of the parse functions on the classes
>altogether, rename the methods on Parser to "parse_Foo" instead of
>"_Foo" (or maybe just leave them), and let the user instantiate the
>Parser object directly if he wants to parse anything.  The reason the
>parse methods on the classes were generated was to provide a nice
>interface to parsing, because the old JavaCUP system was a little
>uglier to use; it also made it easy to convert to JavaCC without
>breaking any existing code.  This last option would cement our
>interface to JavaCC, but this may not be all that bad; even if things
>change drastically, it should be pretty easy to provide the same
>interface of a class named "Parser" with all the parse methods.
>Another small advantage to using the Parser class directly is that the
>user can choose to re-use existing Parser objects (calling .ReInit()
>before reuse), which may be a small performance gain.
>
>Or we can just leave it as is, and not provide any documented
>interface for parsing abstract classes.  This seems to have worked
>okay so far...
>
>--Doug
>

Parsing works very well the way it is. Let's be user driven. If a user asks
for instantiating the parser class herself, we can reconsider this change.

-- Karl

>By "should this be documented" I mean not just "should this usage be
>described in the User Manual" but "should this be an official part of
>the specification of the language, and supported indefinitely".  Maybe
>it can fall somewhere in between (i.e. described with caveats), for

I agree that this is in the category:
useful feature which might not be supported in the future