ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: suggestion : Ant 1.8 full dist to include a 'scripting lang'
Date Fri, 22 Sep 2006 04:35:04 GMT
Kevin Jackson wrote:
>> Kevin, anything in particular you don't like about Groovy?
> Hi Paul,
> Nice to 'chat' to you :)
> My major problem with groovy was it's instability - every time I
> looked at it previously, something was mentioned as still being
> unstable etc.

Yes, it has had an interesting history with a few road bumps.

>> <groovy>
>> def scanner = ant.fileScanner {
>>    fileset(dir: properties['src.dir']) {
>>         include(name: '**/*.xml')
>>    }
>> }
> ok, so we have a chance to make a 'new' language and we can already
> see what 'works' or doesn't work - we are making it for the JVM and we
> want this to be adopted by non-Java programmers as well as Java people
> - why carry all those braces?  Perl had them for no particular reason,
> and practically every new dynamic language has dropped them (for good
> reason) - so why did groovy choose to keep them?  I'd actually be
> interested to know if it's simply because Java programmers are used to
> braces?

Well, I wasn't involved at the time when many of these things were
set in concrete. One of the goals though was to be a scripting language
friendly to Java developers.

> also def is being used here to define a new procedure or is it
> assigning a block of code to a varaible?

def is being used to declare an untyped variable. You can either have
your compile-time checked typing as in Java or leave out the type and
replace it with def to indicate dynamic typing.
(It can also be used to define methods but that is not what is being
used here. The perhaps unusual feature being used here is builder
capability which lets you define your own DSLs. In this case, each
set of braces indicates another level of nesting as you would have
in XML in your ant build file.)

> Having just checked out the groovy site for the first time in years (I
> admit I've not bothered keeping up with it as it seemed to be taking a
> long time to get to a release), I notice this:\
> def map = [name:"Gromit", likes:"cheese", id:1234]
> Ouch!  map is a functional term, in groovy though map means
> associative array/plist/dictionary/HashMap.
> When I read groovy has native support for maps, I though cool!
> list = [1,2,3].map( i : i*2) (or similar)

Maps are the same as in Java with some syntactic sugar.
You can use closures with lists:

list = [1,2,3].collect{ i -> i * 2 }
assert list == [2,4,6]

And similar things with maps, e.g.:

daylengths = [:] // empty map 'daylengths'
['Tuesday', 'Wednesday', 'Thursday'].each{
    day -> daylengths[day] = day.length()
} // fill 3 day, daylength entries into map
println daylengths.findAll{ key -> key =~ 'T.*y' }

Will print the map entries with keys matching the
regex 'T.*y', i.e.:

{Tuesday=7, Thursday=8}

> Well anyway, that's just a couple of reasons why I'm not as keen on
> groovy as other people are - that said, I'll have to download the
> latest version and play with it to re-evaluate it - after all if
> Manning are publishing a book, perhaps it's now ready for prime-time
> :)

I certainly think it is getting close. There are still plenty of
things to do and still things under minor change and still heaps
of marketing to be done if Groovy is to approach the success of Ruby
let alone Java but it isn't too bad.

> Thanks for the feedback (I'm an old curmudgeon too and groovy just
> sounds wrong as a name ;)

Well, when we come up with the Groovy replacement, we can call it Crusty! ;)

> Kev

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message