[groovy-dev] Collection.apply

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[groovy-dev] Collection.apply

Russel Winder
There appears to be no Collection.apply ( Closure c )  method.  Is this
just an extension I should put in JIRA or is there a reason it isn't
there?

Thanks.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Collection.apply

Russel Winder
Also, Groovy does not have the any and all Boolean methods that Ruby
already has and Python is going to be introducing.  Clearly Groovy
should not just follow blindly but it might be worth consideration?

OK, I should just create a patch, I know.  I guess if I stop emailing
and start coding . . .  :-)
--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [groovy-dev] Collection.apply

Dierk König
Groovy has the object iteration methods
'any' and 'every' that may serve your purpose.

> -----Original Message-----
> From: Russel Winder [mailto:[hidden email]]
> Sent: Donnerstag, 3. November 2005 11:02
> To: [hidden email]
> Subject: Re: [groovy-dev] Collection.apply
>
>
> Also, Groovy does not have the any and all Boolean methods that Ruby
> already has and Python is going to be introducing.  Clearly Groovy
> should not just follow blindly but it might be worth consideration?
>
> OK, I should just create a patch, I know.  I guess if I stop emailing
> and start coding . . .  :-)
> --
> Russel.
> ====================================================
> Dr Russel Winder                +44 20 7585 2200
> 41 Buckmaster Road              +44 7770 465 077
> London SW11 1EN, UK             [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

RE: [groovy-dev] Collection.apply

Russel Winder
On Thu, 2005-11-03 at 11:26 +0100, Dierk Koenig wrote:
> Groovy has the object iteration methods
> 'any' and 'every' that may serve your purpose.

Thanks, that saved me some effort: any is any and every is all.  Groovy
beat Python :-) However, it raises a point that methods that apply to
Collections are in Object and also in Collections.  Two points actually:

1. Given that all references are Objects then the methods need to be in
Object but this means extra code to handle the cases where the objects
are not Collections.

2.  Looking up a method is really irritating because the documentation
does present all the methods applicable for a type.  Difficult with
simple auto generation.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Collection.apply

Guillaume Laforge
Administrator
On 03/11/05, Russel Winder <[hidden email]> wrote:
> [...]
> Thanks, that saved me some effort: any is any and every is all.  Groovy
> beat Python :-)

any, every, each, find, findAll... :-)

> [...]
> 2.  Looking up a method is really irritating because the documentation
> does present all the methods applicable for a type.  Difficult with
> simple auto generation.

I'm guilty for the original implementation of our DocGenerator.
I think it diserves some improvements.
It should probably look more like the standard JavaDoc, where you can
see inherited methods as well from super types.

Feel free to improve it if you have some spare time ;-))))

--
Guillaume Laforge
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Collection.apply

tugwilson
In reply to this post by Russel Winder

On 3 Nov 2005, at 10:33, Russel Winder wrote:

> Thanks, that saved me some effort: any is any and every is all.  
> Groovy
> beat Python :-) However, it raises a point that methods that apply to
> Collections are in Object and also in Collections.  Two points  
> actually:
>
> 1. Given that all references are Objects then the methods need to  
> be in
> Object but this means extra code to handle the cases where the objects
> are not Collections.

they also work on iterators and you can't tell by looking at the type  
of an object if it is capable of iterating.

>
> 2.  Looking up a method is really irritating because the documentation
> does present all the methods applicable for a type.  Difficult with
> simple auto generation.

Good point - t would certainly be possible to produce a script, based  
on DocGenerator, which did a a JavaDoc style job of showing all the  
methods - fancy having a go?


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Collection.apply

Russel Winder
In reply to this post by Guillaume Laforge
On Thu, 2005-11-03 at 11:41 +0100, Guillaume Laforge wrote:

> any, every, each, find, findAll... :-)

Of course.  Basically I failed to look under Object for all these
Collections related methods.  Silly me :-)

> I'm guilty for the original implementation of our DocGenerator.
> I think it diserves some improvements.
> It should probably look more like the standard JavaDoc, where you can
> see inherited methods as well from super types.

Guilty is certainly the wrong label.  Responsible sounds much better.
After all it does work and do what is was intended to do.

I agree the output should be more like JavaDoc simply for consistency.
Is there a way of running JavaDoc and a custom Doclet to handle this
rather than a specialist bit of Java?  I guess it depends how the
generation happens.

> Feel free to improve it if you have some spare time ;-))))

That's the problem with providing critique, someone always comes along
and suggest doing some actual work ;-)

I probably could have a look at it but my short term focus has to be on
creating a 90min presentation on Groovy to a C++ / Python / C / Java
(numbers in that order) audience.  At the moment I am trying to build a
suitable story line to show the C++ and C programmers that scripting is
cool and the Python programmers that they are using the wrong language!
Java people are generally easy to win over to Groovy you just tell them
about the lack of syntax, scripts and closures.

--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Collection.apply

Guillaume Laforge
Administrator
On 03/11/05, Russel Winder <[hidden email]> wrote:
> [...]
> Guilty is certainly the wrong label.  Responsible sounds much better.
> After all it does work and do what is was intended to do.

;-)

> I agree the output should be more like JavaDoc simply for consistency.
> Is there a way of running JavaDoc and a custom Doclet to handle this
> rather than a specialist bit of Java?  I guess it depends how the
> generation happens.

I think I might have a look at Sun's doclet stuff soon, because I want
to make a GroovyDoc tool that would parse both Java source code as
well as Groovy source code. So I might give you soon some information
on that topic. And perhaps an additional custom doclet could be
written to generate the groovy-jdk document as well.


--
Guillaume Laforge
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Collection.apply

Russel Winder
On Thu, 2005-11-03 at 11:56 +0100, Guillaume Laforge wrote:

> I think I might have a look at Sun's doclet stuff soon, because I want
> to make a GroovyDoc tool that would parse both Java source code as
> well as Groovy source code. So I might give you soon some information
> on that topic. And perhaps an additional custom doclet could be
> written to generate the groovy-jdk document as well.

I have done a custom Doclet in the past to generate API information from
a code base to go into LaTeX documents. It isn't that hard.  Of course
the input has to be Java.  JavaDoc uses the standard JDK Compiler I
believe but I don't think this is pluggable.  So to create a GroovyDoc
we have to have a Groovy compiler (I think we probably have one :-) and
then fit the parse tree into the standard Doclet / Taglet etc. back end
from JavaDoc.  Non trivial but it should give us the best way forward.
Saves writing something from scratch.

First stop is of course knowing the Groovy parse tree representation and
the Java compiler parse tree representation and creating a mapping
between the two.  Then find out if the JavaDoc source is available or at
least the classes compiled as part of the JDK.  
--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Collection.apply

tugwilson
In reply to this post by Russel Winder

On 3 Nov 2005, at 10:52, Russel Winder wrote:

>> any, every, each, find, findAll... :-)
>
> Of course.  Basically I failed to look under Object for all these
> Collections related methods.  Silly me :-)

they are not really collection related. They are also related to ant  
object which can be cajoled into producing an Iterator. I make  
extensive use of this in the GPath implementation returned from  
XmlSlurper.

it's also surprisingly useful that

def x = 1
....
x.each{ println it}

works and prints 1


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


12