[antlr-interest] Re: Request enhancement ANTLR
Brian Smith
brian-l-smith at uiowa.edu
Sat Sep 14 21:57:42 PDT 2002
Terence,
May I recommend that instead of getFilename/setFilename, you have getURL
and setURL()? I am using ANTLR inside of NetBeans and I've added an
extension just as you described. With NetBeans they have a filesystem
abstraction that uses URL's of the form nbfs://XXXX to identify files,
so I can't use a "filename" per se. Also, get/setFilename wouldn't be
very useful for parsing from a HTTP stream.
Terence Parr wrote:
> I've added getFilename/setFilename methods (empty impl) to Token.java,
> but I'm not sure about adding the ctor to NoViableAltException and the
> code generator. Seems that now you'll get the filename but unless I
> add real functionality to Token it will have a bogus default filename.
> Hmm...plus, what about other exceptions? Seems I'd have to make wide
> changes. I'll add the basic interface for now and see what happens I
> guess.
>
> Ok, in 2.7.2a3.
>
> Thanks,
> Ter
> On Tuesday, June 25, 2002, at 09:12 AM, Dennis Marsa wrote:
>
>
>>Silvain Piree wrote:
>>
>>>>You're right that getFilename() may not return something
>>>>useful, but it could return something indicating that the
>>>>filename is not there, either an empty string, or "<no file>",
>>>>or something.
>>>
>>>Sounds reasonable, but wouldn't it impact existing users,
>>>who depend on the getFilename() behaviour?
>>
>>I don't think so.
>>
>>To be explicit, I'm suggesting adding a new NoViableAltException
>>constructor. The existing two argument (token, filename) constructor
>>could stay for compatibility reasons.
>>
>>public class NoViableAltException extends RecognitionException {
>>
>> // suggested new constructor
>> public NoViableAltException(Token t) {
>> super("NoViableAlt", t.getFilename(), t.getLine(),
>>t.getColumn());
>> token = t;
>> }
>>
>> // existing constructor
>> public NoViableAltException(Token t, String fileName_) {
>> super("NoViableAlt", fileName_, t.getLine(), t.getColumn());
>> token = t;
>> }
>>
>> <remainder of class definition omitted for brevity>
>>}
>>
>>
>>But, it seems most NoViableAltException constructions are generated by
>>ANTLR, so it could easily be updated to use the new single-argument
>>constructor without impacting users.
>>
>>Any existing explicit NoViableAltException constructions made by the
>>user would still get the two-argument version, but could be updated
>>to use the single-argument version.
>>
>>Dennis
>>
>>
>>
>>Your use of Yahoo! Groups is subject to
>>http://docs.yahoo.com/info/terms/
>>
>>
>
> --
> Co-founder, http://www.jguru.com
> Creator, ANTLR Parser Generator: http://www.antlr.org
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
More information about the antlr-interest
mailing list