Usage of Groovy ()

Jochen Theodorou | 1 Feb 2009 03:50

Re: [groovy-user] Probably a nasty bug in 1.5.7 and 1.6-RC-2

Roshan Dawrani schrieb:
> I tried working on a fix for this issue on 1.5.x and 1.6.x and the fix 
> is breaking the following 3 tests, which are anyway running contrary to 
> the current understanding of how String to String[] transformation 
> should happen:
> 
> 1)  groovy.GroovyMethodsTest.testStringToList
>     *   asserts
>         *   'hello 10' as String[] == ["h", "e", "l", "l", "o", " ", "1", "0"]
>         *   "hello ${5 + 5}"  as String[] == ["h", "e", "l", "l", "o", " ", "1", "0"]
> 
> 2)  Groovy1617_Bug.testCoerceStringIntoStringArray()
>     *   asserts "Groovy" as String[] == ["G","r","o","o","v","y"] as String[]
> 
> 3)  Groovy1617_Bug.testCoerceGStringIntoStringArray()
>     *   asserts "$a$b" as String[] == ["G","r","o","o","v","y"] as String[] (a = "Gro", b = "ovy")
> 
> So, these tests should also be adjusted according to this new 
> understanding of the transformation, right?

hmm... that is asType here, that can behave different. 1617 was about 
GString and String behaving equal, not about how they should behave. 
Changing the transformation doesn't mean it has to change there too...

I did see it is also used in isCase... and it seems it is not tested.. 
how should it behave there?

> The change I have done is to DefaultTypeTransformation.asArray(Object 
> object, Class type) as below:
>

(Continue reading)

headers

Jochen Theodorou | 1 Feb 2009 03:59

Re: [groovy-user] Probably a nasty bug in 1.5.7 and 1.6-RC-2

Jim White schrieb:
> I don't agree.  Groovy treats arrays and collections equivalently.
> 
> The bug I see in the original example is that the method call and the 
> property assignment behave differently.
> 
> As iteration on String shows, the one that is correct is the property 
> assignment (which properly does assignment conversion), while the method 
> call's parameter assignment is incorrect - or at least ambiguous.

just because you can iterate on a string does not mean it should be 
converted like that in a method call. In fact for the method calls we 
follow the java convention and that is to wrap the string in a single 
element array. This follows naturally from the way vargs are handled in 
general. If we wanted to follow the property assignment, then we would 
have to introduce a special case here.

There is another solution we should think about.... throwing an 
exception. Why should a assignment create an array or of something that 
is no collection?

> I suspect the trouble with the method call is that the handling of 
> varargs makes in uncertain which is intended when a conversion to a list 
> is possible (as with a String).

If you have a propoerty of type Integer and a value of type ArrayList, 
then Groovy would still try to convert the ArrayList into a Integer and 
then fail while doing so. The logic there is quite stupid and does not 
chec the type. If there is a conversion rule, even if that wouldn't be 
done normally, then it will still be done.

(Continue reading)

headers

Jim White | 1 Feb 2009 05:13

Re: [groovy-user] Probably a nasty bug in 1.5.7 and 1.6-RC-2

Jochen Theodorou wrote:

> Jim White schrieb:
> 
>> I don't agree.  Groovy treats arrays and collections equivalently.
>>
>> The bug I see in the original example is that the method call and the 
>> property assignment behave differently.
>>
>> As iteration on String shows, the one that is correct is the property 
>> assignment (which properly does assignment conversion), while the 
>> method call's parameter assignment is incorrect - or at least ambiguous.
> 
> just because you can iterate on a string does not mean it should be 
> converted like that in a method call. In fact for the method calls we 
> follow the java convention and that is to wrap the string in a single 
> element array. This follows naturally from the way vargs are handled in 
> general. If we wanted to follow the property assignment, then we would 
> have to introduce a special case here.
> ...

The problem here has nothing to do with String and it's default 
conversion to List.

If you look at my additional examples it is the fact that varargs (which 
is any method whose last parameter is an array) is *blocking* the normal 
assignment conversion.

The case (and it is easy to generate many examples) is ambiguous and 
pretty much unavoidable AFAICT.

(Continue reading)

headers

Roshan Dawrani | 1 Feb 2009 05:44

Re: [groovy-user] Probably a nasty bug in 1.5.7 and 1.6-RC-2

Regarding the option to throw an exception when converting String to String[] - we are actually talking about all such cases and not specifically String->String[], right?

I mean, calling f(10) to invoke f(int[]) converts 10 to [10]. Even cases like that should be consistent with String/String[] and start throwing exception then, right?

On Sun, Feb 1, 2009 at 9:43 AM, Jim White <jim <at> pagesmiths.com> wrote:

Jochen Theodorou wrote:

Jim White schrieb:

I don't agree. Groovy treats arrays and collections equivalently.

The bug I see in the original example is that the method call and the property assignment behave differently.

As iteration on String shows, the one that is correct is the property assignment (which properly does assignment conversion), while the method call's parameter assignment is incorrect - or at least ambiguous.

just because you can iterate on a string does not mean it should be converted like that in a method call. In fact for the method calls we follow the java convention and that is to wrap the string in a single element array. This follows naturally from the way vargs are handled in general. If we wanted to follow the property assignment, then we would have to introduce a special case here.

...

The problem here has nothing to do with String and it's default conversion to List.

If you look at my additional examples it is the fact that varargs (which is any method whose last parameter is an array) is *blocking* the normal assignment conversion.

The case (and it is easy to generate many examples) is ambiguous and pretty much unavoidable AFAICT.

The property assignment calling the setter is correct and consistent behavior (note it is the same behavior for assignment to an array variable) and does conversion as appropriate.

So if you want to do something different, it would have to do with varargs. The conversion stuff happens just fine and is correct when the method calling logic doesn't get in the way.

Jim

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

http://xircles.codehaus.org/manage_email

headers

Roshan Dawrani | 1 Feb 2009 06:31

[groovy-user] Should mixin exclude some standard methods

Hi,
I have a basic question about mixin feature.

Should mixin functionality exclude delegation for standard methods like those of Object/GroovyObject? Else, it seems a bit confusing to me. For example, in the snippet below:
------------------------------------------------------------------
class MyInteger {
    static minus(int self, int other) {
        // 1) prints false because call self.getClass() delegates to mixin class MyInteger and is this MyInteger
        println self.getClass().equals(Integer)

        // 2) prints true because self is of-course an instance of Integer
        println (self instanceof Integer)

        return self + other
    }
}
Integer.mixin MyInteger
2 - 3
------------------------------------------------------------------
Aren't results 1) and 2) above a little contradictory? So, should mixin avoid delegation for basic, standard methods to not tamper with such basic understanding?

rgds,
Roshan

headers

Roshan Dawrani | 1 Feb 2009 06:49

[groovy-user] Re: Should mixin exclude some standard methods

Seems like categories don't have this problem:

class IntegerCategory {
    static minus(Integer self, Integer other) {
        println self.getClass() // prints "class java.lang.Integer"
        return self + other
    }
}

use (IntegerCategory) {
    2 - 3
}

In case of categories, the delegation happens only for the methods defined as static in the Category class. So it avoids doing the delegation for all Object/GroovyObject methods.

Why is it different for mixin? If, for some reason, it wants to delegate to non-static methods of mixin Class, should it not exclude the Object/GroovyObject methods?

rgds,
Roshan

On Sun, Feb 1, 2009 at 11:01 AM, Roshan Dawrani <roshandawrani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hi,
I have a basic question about mixin feature.

Should mixin functionality exclude delegation for standard methods like those of Object/GroovyObject? Else, it seems a bit confusing to me. For example, in the snippet below:
------------------------------------------------------------------
class MyInteger {
    static minus(int self, int other) {
        // 1) prints false because call self.getClass() delegates to mixin class MyInteger and is this MyInteger
        println self.getClass().equals(Integer)

        // 2) prints true because self is of-course an instance of Integer
        println (self instanceof Integer)

        return self + other
    }
}
Integer.mixin MyInteger
2 - 3
------------------------------------------------------------------
Aren't results 1) and 2) above a little contradictory? So, should mixin avoid delegation for basic, standard methods to not tamper with such basic understanding?

rgds,
Roshan

headers

Guillaume Laforge | 1 Feb 2009 09:56

[groovy-user] Twitter plugin

Hi,

I just installed the twitter plugin, but noticed that some stuff were
compiled with Java 6, which means the plugin is not usable on Grails
running on JDK 5.
Would be good to have the libs recompiled with JDK 5.

--

-- 
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

    http://xircles.codehaus.org/manage_email

headers

ales | 1 Feb 2009 10:54

Re: [groovy-user] How to Write Doc Comments for the Groovydoc Tool?

Hi Paul,
thanks for your response. I can confirm that in Grails 1.1-beta3 it
works as you mentioned. Great!

Best regards,

Ales

Paul King  wrote / napísal(a):
>
> Hi Ales,
>
> Earlier versions of GroovyDoc didn't support such comments.
> The latest version (Groovy-1.6-RC-2) does and this should
> be in Grails 1.1-beta3. At the moment properties are listed
> as 'fields' they eventually should be listed as 'properties'.
>
> Cheers, Paul.
>
> ales wrote:
>> Hi all,
>> please help me to clarify documentation generation using Groovydoc. I
>> could not find any useful information about this (or I am blind 
>> ). I am developing Grails application and I have domain class:
>>
>> /**
>>  * This documentation *is visible*.
>>  */
>> class SpecialFoo extends BaseFoo {
>>     /**
>>      * This documentation *is invisible*.
>>      */
>>     String sourceDevice
>>     /**
>>      * This documentation *is invisible*.
>>      */
>>     String targetDevice
>> }
>>
>> Why property comments are not visible in the generated documentation?
>> Exists document which described how to document Groovy class and
>> which documentation comments are supported? Something like *How to
>> Write Doc Comments for the Javadoc Tool*
>> (http://java.sun.com/j2se/javadoc/writingdoccomments/index.html)?
>>
>> Best regards,
>>
>> Ales
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>> http://xircles.codehaus.org/manage_email
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

headers

Graeme Rocher | 1 Feb 2009 11:03

Re: [groovy-user] Twitter plugin

Grails list?

On Sun, Feb 1, 2009 at 8:56 AM, Guillaume Laforge <glaforge@...> wrote:
> Hi,
>
> I just installed the twitter plugin, but noticed that some stuff were
> compiled with Java 6, which means the plugin is not usable on Grails
> running on JDK 5.
> Would be good to have the libs recompiled with JDK 5.
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--

-- 
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

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

    http://xircles.codehaus.org/manage_email

headers

Jochen Theodorou | 1 Feb 2009 16:37

Re: [groovy-user] Probably a nasty bug in 1.5.7 and 1.6-RC-2

Jim White schrieb:
> Jochen Theodorou wrote:
> 
>> Jim White schrieb:
>>
>>> I don't agree.  Groovy treats arrays and collections equivalently.
>>>
>>> The bug I see in the original example is that the method call and the 
>>> property assignment behave differently.
>>>
>>> As iteration on String shows, the one that is correct is the property 
>>> assignment (which properly does assignment conversion), while the 
>>> method call's parameter assignment is incorrect - or at least ambiguous.
>>
>> just because you can iterate on a string does not mean it should be 
>> converted like that in a method call. In fact for the method calls we 
>> follow the java convention and that is to wrap the string in a single 
>> element array. This follows naturally from the way vargs are handled 
>> in general. If we wanted to follow the property assignment, then we 
>> would have to introduce a special case here.
>> ...
> 
> The problem here has nothing to do with String and it's default 
> conversion to List.
> 
> If you look at my additional examples it is the fact that varargs (which 
> is any method whose last parameter is an array) is *blocking* the normal 
> assignment conversion.

assignment and method calls do not have the same relation in Groovy as 
they have in Java. In Java a method call can be explained as an 
assignment with an extra rule for vargs. In Groovy the basics are the 
same, but that's it. The method calls do follow the java semantics 
mostly, the assignment may try to eagerly convert any value to the goal 
type. As a result I can assign a collection to an array, but I cannot 
easily call a method that takes an array with a collection.

> The case (and it is easy to generate many examples) is ambiguous and 
> pretty much unavoidable AFAICT.

after thinking about it for a while you might be right. if a property is 
of type String[] and I assign a String to it, then it will be different 
from putting the String i a one-element-array first... which is unlike 
what happens for a method call... is that even ambiguous? Probably only 
when we say that foo.bar = x is executed as foo.setBar(x), which is not 
the case. It is ok as a model to understand it, but it should be more 
like foo.setBar((Bar)x) and then you would see the split too.

> The property assignment calling the setter is correct and consistent 
> behavior (note it is the same behavior for assignment to an array 
> variable) and does conversion as appropriate.
> 
> So if you want to do something different, it would have to do with 
> varargs.  The conversion stuff happens just fine and is correct when the 
> method calling logic doesn't get in the way.

I more and more come to think that we should not do anything

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

Mon	Tue	Wed	Thu	Fri	Sat	Sun

						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28

127	June 2013
348	May 2013
260	April 2013
475	March 2013
521	February 2013
277	January 2013
208	December 2012
206	November 2012
255	October 2012
280	September 2012
151	August 2012
278	July 2012
314	June 2012
220	May 2012
159	April 2012
389	March 2012
309	February 2012
238	January 2012
246	December 2011
258	November 2011
349	October 2011
558	September 2011
277	August 2011
336	July 2011
444	June 2011
554	May 2011
578	April 2011
560	March 2011
559	February 2011
473	January 2011
354	December 2010
342	November 2010
487	October 2010
386	September 2010
264	August 2010
405	July 2010
510	June 2010
529	May 2010
526	April 2010
608	March 2010
400	February 2010
764	January 2010
636	December 2009
573	November 2009
606	October 2009
577	September 2009
805	August 2009
666	July 2009
573	June 2009
646	May 2009
761	April 2009
948	March 2009
679	February 2009
866	January 2009
549	December 2008
602	November 2008
617	October 2008
765	September 2008
684	August 2008
693	July 2008
791	June 2008
1018	May 2008
1093	April 2008
818	March 2008
987	February 2008
1039	January 2008
1171	December 2007
1072	November 2007
946	October 2007
1078	September 2007
1152	August 2007
1101	July 2007
1138	June 2007
1503	May 2007
1579	April 2007
1578	March 2007
1233	February 2007
1522	January 2007
824	December 2006
650	November 2006
243	October 2006
1	August 2006
42	June 2006
251	May 2006
576	April 2006
656	March 2006
278	February 2006
291	January 2006
454	December 2005
498	November 2005
315	October 2005
339	September 2005
289	August 2005
487	July 2005
281	June 2005
201	May 2005
192	April 2005
286	March 2005
128	February 2005
333	January 2005
315	December 2004
204	November 2004
174	October 2004
186	September 2004
134	August 2004
241	July 2004
249	June 2004
213	May 2004
501	April 2004
495	March 2004
221	February 2004
46	January 2004