[antlr-interest] Java string array issue in v3.
open.zone at virgin.net
Sat Jun 16 17:40:59 PDT 2007
While I don't doubt that not requiring escapes is a good thing, V2 wasn't
any different in dealing with brackets within argument action blocks. At
least, I don't remember that it was...
The best way to contact me is via the list/forum. My time is very limited.
From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Gavin Lambert
Sent: 16 June 2007 22:48
To: ANTLR mail-list
Subject: Re: [antlr-interest] Java string array issue in v3.
At 06:38 17/06/2007, Kay Roepke wrote:
>FYI, the above URL has a comment describing the fix. When (and if)
>that goes through, you will be able to escape '[' and ']'
>characters in rule arguments, thus allowing things like String
>strArray as parameters.
Why can't it be implemented like it was in v2, which didn't require any
escaping at all?
IIRC it maintained a count of opened square brackets, so the sequence:
start[HashMap fieldMap, String fqls]
would be interpreted something like this:
- rulename 'start'
- open parameter block '[' (incrementing "number of square brackets" to
- parameter 1 type 'HashMap'
- parameter 1 name 'fieldMap'
- parameter separator ','
- parameter 2 type 'String' (incrementing then decrementing its internal
"number of square brackets" counter to avoid exiting the parameter block)
- parameter 2 name 'fqls'
- end of parameter list ']' (close square bracket encountered when "number
of square brackets" was one)
I guess escaping is more robust in pathological cases (where the target
language requires unbalanced square brackets), but I can't think of any
common language where that is the case, so I don't think it's worth worrying
about. Escaping should probably be supported regardless (as a matter of
course), but my point is that it shouldn't be *required* in this case.
Escaping is unnatural.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the antlr-interest