Writing a document on Groovy... want to get things right

[Moe-25]

Please help me point out whatever statements I am making that are incorrect : 

"

>> groovysh
 
This command will start the groovysh command-line shell, which can be used to execute code interactivly “on the fly”. Here is an example:
 
>> print ‘Hello, World!’
>> System.out.print(“Hello, World!”);
 
hello, world===> null
 
Both these calls, the first being the Groovy way and the second the Java way will output the text to the console along with a return value. Groovy removes the need for you to explicitly type return at the end of scripts and methods and will return the value placed at the bottom. In this case, there was nothing to return so a null value was returned.

"

I am trying to clarify the output to the reader but I am unsure of it myself. How would you explain the null output here?

Thanks / Moe

[Martin-310]

Moe pisze:

>
> Please help me point out whatever statements I am making that are
> incorrect :
>
>
> "
> >> groovysh
>  
> This command will start the groovysh command-line shell, which can be
> used to execute code interactivly “on the fly”. Here is an example:
>  
> >> print ‘Hello, World!’
> >> System.out.print(“Hello, World!”);
>  
> hello, world===> null
>  
> Both these calls, the first being the Groovy way and the second the
> Java way will output the text to the console along with a return
> value. Groovy removes the need for you to explicitly type return at
> the end of scripts and methods and will return the value placed at the
> bottom. In this case, there was nothing to return so a null value was
> returned.
>
> "
>
> I am trying to clarify the output to the reader but I am unsure of it
> myself. How would you explain the null output here?
>
> Thanks / Moe

Hi Moe,

Isn't it what you are looking for?:
http://groovy.codehaus.org/Tutorial+1+-+Getting+started

<cite>
The line starting with "groovy>" is just the text of what the console
processed. The "null" is what the expression "evaluated to". Turns out
the expression to print out a message doesn't have any "value" so the
groovyConsole printed "null".
</cite>

--
Greets,
Marcin

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Moe-25]

Thanks!

I just started this work and I am guessing I am going to be asking lots of more question in the near future so I will try to keep my questions within this thread.

[Moe-25]

I have a new question concerning the safe navigation operator. 

---

...

By providing the safe navigation operator we can use our objects internals without having to worry about the object being null. If the object is null, the same expression will return false. It's on this front that Groovy might get confusing and where one needs to be careful not to make simple mistakes.

String str = null;

/* 1 */ 

if( str?.contains('i') == false ) println '1. no print'

/* 2 */ 

if( !str?.contains('i') ) println '2. Will print'

--------- Comment ------

I want to explain what happens in the last part above and why groovy interprets them differently.

---------Continue---------

What Groovy does is to rewrite the condition where the safe navigation operator is being used by adding the null comparison for you. <--- Is this something I can say ? How can I put it better?

/* Rewrite of 1 */ 

if( (str != null && str.contains('i') == false) ) println '3. no print'

/* Rewrite of 2 */ 

if( !(str != null && str.contains('i') ) ) println '4. Will print'

(is this how it's done?) 

Thanks / Moe

[HamletDRC]

What you're trying to explain is the intersection between two language
features: Groovy Truth and Elvis Operator.

I would suggest introducing each concept separately, but then use your
last example to show how the features used together compliment each
each. That's synergy, baby.

--
Hamlet D'Arcy
hamletdrc@...




On Mon, Jul 27, 2009 at 5:58 AM, Moe<mohamed5432154321@...> wrote:

> I have a new question concerning the safe navigation operator.
> ---
> ...
> By providing the safe navigation operator we can use our objects internals
> without having to worry about the object being null. If the object is null,
> the same expression will return false. It's on this front that Groovy might
> get confusing and where one needs to be careful not to make simple mistakes.
> String str = null;
> /* 1 */
> if( str?.contains('i') == false ) println '1. no print'
> /* 2 */
> if( !str?.contains('i') ) println '2. Will print'
> --------- Comment ------
> I want to explain what happens in the last part above and why groovy
> interprets them differently.
> ---------Continue---------
> What Groovy does is to rewrite the condition where the safe navigation
> operator is being used by adding the null comparison for you. <--- Is this
> something I can say ? How can I put it better?
>
> /* Rewrite of 1 */
> if( (str != null && str.contains('i') == false) ) println '3. no print'
> /* Rewrite of 2 */
> if( !(str != null && str.contains('i') ) ) println '4. Will print'
> (is this how it's done?)
> Thanks / Moe

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Hamlet D'Arcy schrieb:
> What you're trying to explain is the intersection between two language
> features: Groovy Truth and Elvis Operator.

?. Is safe navigation, ?: is the Elvis operator

> I would suggest introducing each concept separately, but then use your
> last example to show how the features used together compliment each
> each. That's synergy, baby.

safe navigation does not use groovy truth! It is only to avoid null checks.

x?.y can be seen as x==null? null : x.y to use the ternary operator.

Now !x?.y was the question and that is indeed !(x?.y). This is according
to the above: !(x==null? null: x.y), which is equals to x==null? !null:
!(x.y). !null is always true, since null is seen as false (groovy truth
here).

So with String str = null;

str?.contains('i') == false

is (str==null? null: str.contains('i')) == false the left side will be
null, since str is null, leaving null == false. Now it is true, that
null will be seen as false in groovy truth, but this transformation is
not done automatically for ==. That means null == false will not be
true, therefor the whole expression will return false.

!str?.contains('i')

is !(str==null? null: str.contains'i'). This will the inner part will
again eval to null, but !null is always true. As a result this
expression will evaluate to true.

bye blackdrag



--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[SophosGuy]

I'm not sure if Groovy technically "rewrites it", I believe it is just the way the Metadata, and Byte Code works. You might say something like "is functionally equivalent to", this way you are covering your bases.

Jackie

On Mon, Jul 27, 2009 at 6:58 AM, Moe <mohamed5432154321@...> wrote:

I have a new question concerning the safe navigation operator. 

---

...

By providing the safe navigation operator we can use our objects internals without having to worry about the object being null. If the object is null, the same expression will return false. It's on this front that Groovy might get confusing and where one needs to be careful not to make simple mistakes.

String str = null;

/* 1 */ 

if( str?.contains('i') == false ) println '1. no print'

/* 2 */ 

if( !str?.contains('i') ) println '2. Will print'

--------- Comment ------

I want to explain what happens in the last part above and why groovy interprets them differently.

---------Continue---------

What Groovy does is to rewrite the condition where the safe navigation operator is being used by adding the null comparison for you. <--- Is this something I can say ? How can I put it better?

/* Rewrite of 1 */ 

if( (str != null && str.contains('i') == false) ) println '3. no print'

/* Rewrite of 2 */ 

if( !(str != null && str.contains('i') ) ) println '4. Will print'

(is this how it's done?) 

Thanks / Moe

[Moe-25]

Thanks Guys, I rephrased everything and now I included the Elvis Operator in an example as well :)

- Moe

[HamletDRC]

>> What you're trying to explain is the intersection between two language
>> features: Groovy Truth and Elvis Operator.
>
> ?. Is safe navigation, ?: is the Elvis operator

Sorry, yes I meant to say safe navigation.

It was the conditional example that uses Groovy Truth and Safe Navigation:

   if( str?.contains('i') == false ) println '1. no print'



On Mon, Jul 27, 2009 at 9:14 AM, Jochen Theodorou<blackdrag@...> wrote:

> Hamlet D'Arcy schrieb:
>>
>> What you're trying to explain is the intersection between two language
>> features: Groovy Truth and Elvis Operator.
>
> ?. Is safe navigation, ?: is the Elvis operator
>
>> I would suggest introducing each concept separately, but then use your
>> last example to show how the features used together compliment each
>> each. That's synergy, baby.
>
> safe navigation does not use groovy truth! It is only to avoid null checks.
>
> x?.y can be seen as x==null? null : x.y to use the ternary operator.
>
> Now !x?.y was the question and that is indeed !(x?.y). This is according to
> the above: !(x==null? null: x.y), which is equals to x==null? !null: !(x.y).
> !null is always true, since null is seen as false (groovy truth here).
>
> So with String str = null;
>
> str?.contains('i') == false
>
> is (str==null? null: str.contains('i')) == false the left side will be null,
> since str is null, leaving null == false. Now it is true, that null will be
> seen as false in groovy truth, but this transformation is not done
> automatically for ==. That means null == false will not be true, therefor
> the whole expression will return false.
>
> !str?.contains('i')
>
> is !(str==null? null: str.contains'i'). This will the inner part will again
> eval to null, but !null is always true. As a result this expression will
> evaluate to true.
>
> bye blackdrag
>
>
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

--
Hamlet D'Arcy
hamletdrc@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Moe-25]

Is there any reason to why the single quoted string isn't GString aware?

Doesn't this limit the usage where one might need to insert double quotes in the text and having to escape those, which is from what I can understand the purpose for providing both quoting ways? Why not the single quote as well?

Moe

[Jochen Theodorou]

Moe schrieb:
> Is there any reason to why the single quoted string isn't GString aware?

we wanted to have one GString aware form and one, that is not.

> Doesn't this limit the usage where one might need to insert double
> quotes in the text and having to escape those, which is from what I can
> understand the purpose for providing both quoting ways? Why not the
> single quote as well?

if you want to write a $ you have to escape it in a GString

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Moe-25]

-- New question ---

Can it be said that find, findAll, collect are iterators (for List) ? 

[Robert Fischer]

Depends on your definition of "iterator".  They are *not* related to java.util.Iterator.

~~ Robert.

Moe wrote:
> -- New question ---
>
> Can it be said that find, findAll, collect are iterators (for List) ?

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Robert Fischer schrieb:
> Depends on your definition of "iterator".  They are *not* related to
> java.util.Iterator.

hmm... I wouldn't say they are not related at all. each, find, collect
use per default the method iterator(), which is partially added by
Groovy (like each, find and collect too) and all that implement
java.util.Iterator do implement that method. So there is a connection,
but the interface is no requirement. Also each, find and collect might
be implemented different if the user decides to do so.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Moe-25]

On Thu, Aug 6, 2009 at 7:24 PM, Jochen Theodorou <blackdrag@...> wrote:

Robert Fischer schrieb:

Depends on your definition of "iterator".  They are *not* related to java.util.Iterator.

Good to know. I was mostly not clear about the definition of an iterator. If it must be a clean one like each. find, collect does some extra operations as well, and perhaps should be seen as methods that take a closure.

 

hmm... I wouldn't say they are not related at all. each, find, collect use per default the method iterator(), which is partially added by Groovy (like each, find and collect too) and all that implement java.util.Iterator do implement that method. So there is a connection, but the interface is no requirement. Also each, find and collect might be implemented different if the user decides to do so.

Ok, but I think I would call each an iterator ( internal iterator, reference: "...Greasing the Wheels of Java" ) and since you have grouped them together , I guess I will continue using that term to describe them as a group of iterators. 

I need some stuff to fill out on the Collections and Iterators section as well :)

Thanks / Moe

[Dierk König]

well, there are a lot of descriptions out there that capture the

intent of the feature but are not complete.

The best advice I can give is to get a copy of Groovy in Action and 

look under GDK "object iteration methods".

If you really want to write a comprehensive document on Groovy, there 

is probably no way around reading Gina.

cheers

Dierk

http://groovy.canoo.com/gina

Am 06.08.2009 um 19:45 schrieb Moe:

On Thu, Aug 6, 2009 at 7:24 PM, Jochen Theodorou <blackdrag@...> wrote:

Robert Fischer schrieb:

Depends on your definition of "iterator".  They are *not* related to java.util.Iterator.

Good to know. I was mostly not clear about the definition of an iterator. If it must be a clean one like each. find, collect does some extra operations as well, and perhaps should be seen as methods that take a closure.

 

hmm... I wouldn't say they are not related at all. each, find, collect use per default the method iterator(), which is partially added by Groovy (like each, find and collect too) and all that implement java.util.Iterator do implement that method. So there is a connection, but the interface is no requirement. Also each, find and collect might be implemented different if the user decides to do so.

Ok, but I think I would call each an iterator ( internal iterator, reference: "...Greasing the Wheels of Java" ) and since you have grouped them together , I guess I will continue using that term to describe them as a group of iterators. 

I need some stuff to fill out on the Collections and Iterators section as well :)

Thanks / Moe

[Robert Fischer]

I'm sticking with not related, as it's purely an implementation detail that comprehension methods
use java.util.Iterator.  For instance, findAll could just as well be an
AbstractCollectionDecorator[1] that wrapped the underlying collection and only provided access to
those elements that passed the check.  There were already conversations on the dev list about
whether some of these methods (or new ones, like the proposed "reshape") should be wrapping the
underlying collection.

[1]
http://commons.apache.org/collections/api-release/org/apache/commons/collections/collection/AbstractCollectionDecorator.html

~~ Robert.

Moe wrote:

> On Thu, Aug 6, 2009 at 7:24 PM, Jochen Theodorou <blackdrag@...
> <mailto:blackdrag@...>> wrote:
>
>     Robert Fischer schrieb:
>
>         Depends on your definition of "iterator".  They are *not*
>         related to java.util.Iterator.
>
>
> Good to know. I was mostly not clear about the definition of an
> iterator. If it must be a clean one like each. find, collect does some
> extra operations as well, and perhaps should be seen as methods that
> take a closure.
>  
>
>
>
>     hmm... I wouldn't say they are not related at all. each, find,
>     collect use per default the method iterator(), which is partially
>     added by Groovy (like each, find and collect too) and all that
>     implement java.util.Iterator do implement that method. So there is a
>     connection, but the interface is no requirement. Also each, find and
>     collect might be implemented different if the user decides to do so.
>
>
>
> Ok, but I think I would call each an iterator ( internal iterator,
> reference: "...Greasing the Wheels of Java" ) and since you have grouped
> them together , I guess I will continue using that term to describe them
> as a group of iterators.
> I need some stuff to fill out on the Collections and Iterators section
> as well :)
>
> Thanks / Moe
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

To get back to the original question: methods like "each", "findAll", "collect", "inject" are often
called "iterator methods" or "comprehension methods".  I prefer the "comprehension methods" name for
two reasons:

1) The "each" method is often specifically called the "iterator" method: it's even called "iter" in
ML derivatives)
2) The fact that these methods are iterating (which implies serial, ordered execution) is an
implementation detail, and can be false in other languages, with fancier kinds of comprehensions
(e.g. "sublist", which is really findAllByIndex), or even when the same abstractions are applied to
other structures (like GORM's "find" and "findAll").

~~ Robert.

Moe wrote:

> On Thu, Aug 6, 2009 at 7:24 PM, Jochen Theodorou <blackdrag@...
> <mailto:blackdrag@...>> wrote:
>
>     Robert Fischer schrieb:
>
>         Depends on your definition of "iterator".  They are *not*
>         related to java.util.Iterator.
>
>
> Good to know. I was mostly not clear about the definition of an
> iterator. If it must be a clean one like each. find, collect does some
> extra operations as well, and perhaps should be seen as methods that
> take a closure.
>  
>
>
>
>     hmm... I wouldn't say they are not related at all. each, find,
>     collect use per default the method iterator(), which is partially
>     added by Groovy (like each, find and collect too) and all that
>     implement java.util.Iterator do implement that method. So there is a
>     connection, but the interface is no requirement. Also each, find and
>     collect might be implemented different if the user decides to do so.
>
>
>
> Ok, but I think I would call each an iterator ( internal iterator,
> reference: "...Greasing the Wheels of Java" ) and since you have grouped
> them together , I guess I will continue using that term to describe them
> as a group of iterators.
> I need some stuff to fill out on the Collections and Iterators section
> as well :)
>
> Thanks / Moe
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Moe-25]

On Thu, Aug 6, 2009 at 7:55 PM, Dierk König <dierk.koenig@...> wrote:

well, there are a lot of descriptions out there that capture the

intent of the feature but are not complete.

The best advice I can give is to get a copy of Groovy in Action and 

look under GDK "object iteration methods".

Are you pushing your book on me? hehe I already have it next to me of course :D (would have been good to have a pdf version to search through though). I have referenced you several times already but sometimes I take the credit ( JK )

reading 9.1.3 you appear to be avoiding the label Iterator though you keep saying Iterate all over the book but seems still to be calling them methods.

I think perhaps Iterative methods might be better and more correct.

Robert, unfortunately I don't have your book, but I will see if my school can order it.

The best advice I can give is to get a copy of Groovy in Action and 

look under GDK "object iteration methods".

If you really want to write a comprehensive document on Groovy, there 

is probably no way around reading Gina.

I am writing this as my masters thesis and the goal is to provide a basic and good understanding of what can be done.

But it's actually on 'Groovy on Grails', and aimed at those with fairly little Java experience, like early computer science students. The Groovy part should cover what is essential to get going with Grails.

Hopefully it will be used as a project on some course and serve as an introduction to Groovy, and Grails. If they want to dig even deeper, I'll make sure to let them now about your books.

My hope is that it will enable them to be more productive and creative at an early stage in their education, which I believe Web development can do very well. I know I could have needed it back then.

I also want to graduate and I have very limited time to do this :D

Let me know if you'd be interested in reviewing it later on. My English is not flawless, as you probably already noticed and I am concerned about my examiner finding incorrect statements or usage (though he probably knows nothing about Groovy or Grails)

-- Moe

[Robert Fischer]

There's no such thing as "Groovy on Grails".  There's Groovy (a programming language), and there's
Grails (a web framework).

~~ Robert.

Moe wrote:

> On Thu, Aug 6, 2009 at 7:55 PM, Dierk König <dierk.koenig@...
> <mailto:dierk.koenig@...>> wrote:
>
>     well, there are a lot of descriptions out there that capture the
>     intent of the feature but are not complete.
>
>     The best advice I can give is to get a copy of Groovy in Action and
>     look under GDK "object iteration methods".
>
>
> Are you pushing your book on me? hehe I already have it next to me of
> course :D (would have been good to have a pdf version to search through
> though). I have referenced you several times already but sometimes I
> take the credit ( JK )
>
> reading 9.1.3 you appear to be avoiding the label Iterator though you
> keep saying Iterate all over the book but seems still to be calling them
> methods.
>
> I think perhaps Iterative methods might be better and more correct.
>
> Robert, unfortunately I don't have your book, but I will see if my
> school can order it.
>
>     The best advice I can give is to get a copy of Groovy in Action and
>
>     look under GDK "object iteration methods".
>
>     If you really want to write a comprehensive document on Groovy, there
>
>     is probably no way around reading Gina.
>
>
> I am writing this as my masters thesis and the goal is to provide a
> basic and good understanding of what can be done.
> But it's actually on 'Groovy on Grails', and aimed at those with fairly
> little Java experience, like early computer science students. The Groovy
> part should cover what is essential to get going with Grails.
> Hopefully it will be used as a project on some course and serve as an
> introduction to Groovy, and Grails. If they want to dig even deeper,
> I'll make sure to let them now about your books.
> My hope is that it will enable them to be more productive and creative
> at an early stage in their education, which I believe Web development
> can do very well. I know I could have needed it back then.
> I also want to graduate and I have very limited time to do this :D
>
> Let me know if you'd be interested in reviewing it later on. My English
> is not flawless, as you probably already noticed and I am concerned
> about my examiner finding incorrect statements or usage (though he
> probably knows nothing about Groovy or Grails)
>
> -- Moe

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email