Keyword collisions (was: [groovy-user] Re: Java World: Build scripts with Groovy and Ant artcicle)

So here's another case where you might run into problems if one of the 
'parts' of your property name is a keyword.  Maybe.  Not sure what the 
parsing is like, but I definitely ran into a problem wrt: with 
AntBuilder and the taskconvert task with it's 'property' attribute.  
For more details, see:

        http://jira.codehaus.org/browse/GROOVY-487

So, what are the rules here, and how do we 'fix' 487?  Do keywords 
sometimes not act like keywords?

NetREXX has an interesting take on this:

        http://www-306.ibm.com/software/awdtools/netrexx/language/nrlkeys.html

However, I have to admit I'm not a big fan of this type of keyword 
handling.  Though I love the fact that it's future-proof.

I would really prefer that keywords are always considered keywords.  It 
feels right.  Less confusing, to some extent.  As a simple use case, if 
I'm using some plain-old text editor that has a simplified set of rules 
to do syntax highlighting, it won't get do weird things like 
highlighting half the terms if following expression as keywords:

        x = my.class.foo.in

I think some form of escaping would be what I'd prefer, but we'd 
somehow have to add an _ to the name, again, so that simplistic parsers 
wouldn't treat the token as a keyword.  Just using _ as a prefix might 
be good enough:

        x = my._class.foo._in

and the runtime would look for _class and if it didn't find it, class.  
Seems treacherous.  Probably some new punctuation prefixing that:

        x = my.@xxxxxxxxxxx@_in

Quite yucky.  So yucky in fact that maybe I could live with a 
NetREXX-like approach ...

Patrick Mueller
pmuellr-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx

On Oct 29, 2004, at 9:00 AM, Laforge Guillaume wrote:

> Hello Patrick,
>
> Interesting, I had an idea along the lines that I didn't commit on CVS.
> It's a GProperties class which would allow us to do things like:
>
> props = new GProperties("build.properties")
> println props.maven.skip.test
> props.my.other.prop = 3
>
> But I can't really create new branches, just read, and modify actual 
> values.
> I'll have another go at it if you think it's useful.
>
>
> --
> Guillaume Laforge
> http://glaforge.free.fr/weblog
>
>
> -----Message d'origine-----
> De : news [mailto:news-WnDAp88bSu3NLxjTenLetw@xxxxxxxxxxxxxxxx]De la part de 
> Patrick Mueller
> Envoyé : vendredi 29 octobre 2004 14:49
> À : groovy-user-81qHHgoATdGxIXFVlbCvtR2eb7JE58TQ@xxxxxxxxxxxxxxxx
> Objet : [groovy-user] Re: Java World: Build scripts with Groovy and Ant
> artcicle
>
>
> I just started converting some build.xml files to build.groovy.  I
> immediately found that I'd like some of my build properties available 
> as
> Groovy variables, so I now do something like this:
>
>     props = new Properties(System.properties)
>     props.load(new FileInputStream('build.properties'))
>
> I should really close the FileInputStream, but this is a build script 
> so
> I don't care that much.
>
> I haven't looked, but it would nice if there was a one-shot addition to
> Properties in the GroovyJDK bits so you could do something like this:
>
>     props = Properties.loadFile('build.properties')
>
> and maybe some others like:
>
>     props = Properties.loadResource(myClass,myResourceName)
>     props = Properties.loadStream(inputStream)