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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
