ternary operator

Re: withReader

On 20 Jan 2004, at 21:54, Volkmann, Mark wrote:
> I'm getting a NullPointerException on the "if" line below.

Unfortunately I think you've found a bug; we've not yet implemented 
break inside a while/for loop yet I don't think. Have added it to JIRA

http://jira.codehaus.org/secure/ViewIssue.jspa?key=GROOVY-141

> Does anyone see anything wrong with this code?
> I know I could do this in a simpler way, but I'm trying to experiment 
> with the "withReader" method.

We'll fix this ASAP. Until then you can use the simpler

import java.io.File
file = new File('myFile.txt')
file.eachLine { line | println line }

or maybe even

import java.io.File
file = new File('myFile.txt')
file.withReader { reader |
   do {
     line = reader.readLine()
     if (null != line) {
       println line
     }
   } while (line != null)
}

>
> import java.io.File
> file = new File('myFile.txt')
> file.withReader { reader |
>   while (true) {
>     line = reader.readLine()
>     if (null == line) break
>     println line
>   }
> }

James
-------
http://radio.weblogs.com/0112098/

groovy-dev & groovy-user added to Gmane

Just a heads up - thanks to Marcus Ahnve both groovy-dev and 
groovy-user are now available on gmane so that folks can use their news 
reader to monitor the mailing list if folks prefer that to using email.

     * News URL: news://news.gmane.org/gmane.comp.lang.groovy.devel
     * Web URL: http://news.gmane.org/gmane.comp.lang.groovy.devel

     * News URL: news://news.gmane.org/gmane.comp.lang.groovy.user
     * Web URL: http://news.gmane.org/gmane.comp.lang.groovy.user

Begin forwarded message:

> From: admin <at> gmane.org (Gmane Administrator)
> Date: 20 January 2004 22:39:22 GMT
> To: groovy-dev-admin@...
> Subject: groovy-dev added to Gmane
>
> We have received a request for adding the
> groovy-dev@... mailing list to the Gmane mail-to-news
> gateway/archive. A subscription request message has been sent. If this
> is contrary to your wishes, please send a mail to admin <at> gmane.org
> saying so, and the list will be removed from Gmane.
>
> Gmane is a mail-to-news portal that never expires its messages.  It
> therefore also functions as a mailing list archive.  It's a
> bi-directional gateway, but Gmane verifies that its users' email
> addresses are valid before passing the messages through the
> news-to-mail gateway.  (Groups can also be made "read-only", which
> means that Gmane won't forward any messages at all to the mailing
> list.)
>
> Gmane can encrypt addresses to make address harvesting difficult, and
> heeds X-No-Archive and related headers.
>
> If you wish to import older archives into Gmane, send a message to
> the Gmane administrators -- just reply to this message.
>
> The following parameters are set for this mailing list:
>
>     * Newsgroup name: gmane.comp.lang.groovy.devel
>     * Mailing list address: groovy-dev@...
>     * The gateway is bi-directional    * Address encryption is off
>     * Spam detection is on
>     * The list is described as:
>       "Development of the Groovy language"
>     * News URL: news://news.gmane.org/gmane.comp.lang.groovy.devel
>     * Web URL: http://news.gmane.org/gmane.comp.lang.groovy.devel
>
> This newsgroup will be created when the first message from the
> mailing list arrives.
>
> For more information about the Gmane project, go to
> <URL: http://gmane.org/>.
>
> This request was handled by
> Lars Magne Ingebrigtsen <larsi@...>.
>
>

James
-------
http://radio.weblogs.com/0112098/

TipOfTheDay

I've just created a page on the Wiki, entitled TipOfTheDay

http://wiki.codehaus.org/groovy/TipOfTheDay

I've just added the first tip.

Everybody should feel free to add any other tip, any pearl of groovy wisdom
one has discovered why playing with Groovy.

--
Guillaume Laforge
http://glaforge.free.fr/weblog/index.php?catid=2&blogid=1

Groovy JDK documentation

Hello groovy hackers,

Maybe you haven't yet noticed, but there is a new page in the user guide
section on the web site:

http://groovy.codehaus.org/groovy-jdk.html

There you will find a page with all the methods that we added to the core
JDK classes to make them more groovy. There is an exhaustive list of
methods, sorted by JDK class to which those methods apply.

For the curious ones, this documentation is automagically generated with
"maven site".
I wrote a neat groovy script (DocGenerator.groovy) which parses the javadoc
of DefaultGroovyMethods (thanks to QDox) and outputs an HTML page.

A word for developers now, when adding/modifying a method in
DefaultGroovyMethods, please try to give as much details in your javadoc
comments (body, return, param, throws).

Guillaume Laforge

RE: Groovy JDK documentation

RE: Groovy JDK documentation

RE: Groovy JDK documentation

Re: Groovy JDK documentation

On 22 Jan 2004, at 16:24, Volkmann, Mark wrote:
> I was looking at DefaultGroovyMethods.java a couple of days ago and 
> wondered if it wouldn't be a good idea to split that class into a few 
> different classes.  For example, GroovyStringMethods.java, 
> GroovyIOMethods.java, GroovySQLMethods.java, ...

I've been wondering that too. Its often quite handy having common 
together; e.g. various implementations of common functions are very 
similar. Though having all this code in one big class is becoming a 
little bit of a code smell.

Maybe we could use come class naming convention like

<prefix>.<packageName>.class.

where prefix = gjdk (say)

to represent the methods for the given class/interface.

e.g.

gjdk.java.lang.String.class.
gjdk.java.lang.Number.class.

then the MetaClass could dynamically load the extra JDK classes at 
runtime. This would allow folks to add extra methods to classes outside 
of the JDK (e.g. W3C DOM or some external Java library) in an 
extensible way.

It'd mean we'd have to patch Guillaume's DocGenerator script too to 
look for gjdk.* for parsing the new methods.

James
-------
http://radio.weblogs.com/0112098/

RE: Groovy JDK documentation

>I've been wondering that too. Its often quite handy having common
>together; e.g. various implementations of common functions are very
>similar. Though having all this code in one big class is becoming a
>little bit of a code smell.

Every class which is over 1000 lines definetely smells.
I was wondering also how we could split that.
Before DocGenerator, I though it was handy to look at a single file to see
all the available methods, but now, I think it's time we split into smaller
pieces.

>Maybe we could use come class naming convention like
><prefix>.<packageName>.class.
>where prefix = gjdk (say)
>to represent the methods for the given class/interface.
>e.g.
>gjdk.java.lang.String.class.
>gjdk.java.lang.Number.class.
>then the MetaClass could dynamically load the extra JDK classes at
>runtime. This would allow folks to add extra methods to classes outside
>of the JDK (e.g. W3C DOM or some external Java library) in an
>extensible way.

Good idea.

>It'd mean we'd have to patch Guillaume's DocGenerator script too to
>look for gjdk.* for parsing the new methods.

No problem!

--
Guillaume Laforge
http://glaforge.free.fr/weblog/index.php?catid=2&blogid=1