[antlr-interest] Re: Request enhancement ANTLR

[Brian Smith]

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/