removing features in Groovy 2

classic Classic list List threaded Threaded
72 messages Options
1234 ... 8
Reply | Threaded
Open this post in threaded view
|

removing features in Groovy 2

Jochen Theodorou
Hi all,

I intend to remove some features in Groovy 2 and would like to hear what
you guys think of that.

(1) automatic list expansion

def foo(a,b){a+b}
assert foo([1,2])==3

The problem with this is for example vargs. if foo takes an Object[],
then instead of mapping each element to elements of the array the list
itself is the one and only element of that array. And if someone wants
real fun, he can do an int[] and be surprised by a ClassCastException.
On top of that we have spread expressions, which work perfectly well in
all those cases.

(2) String as char

int i = "0"
int j = "10"

while the first one works, the second one will not. The background for
this is, that "0" is handled as if it where a char, leading to a
possible conversion to int based on the index value of the String/char.
That cannot work for the j case, since this is a String not easily
expressed as char. So we end up with a casting problem for that one.
Luckily this conversion does not take part in method calls. I have no
problem supporting

char c="0"

but I think the int/long/byte/short/double/float versions actually go a
bit too far.

(3) automatic null expansion

def foo(x){x}
assert foo()==null

This was already mentioned by me several years ago, in which we had to
keep it to keep SwingBuilder working. I think back then we didn't have
an real optional "it" in Closures, requiring this trick play to go
around the issue. But now we have optional values and I think there is
no need for this version of method call logic beyond reason.... and that
does not work with primitives as well of course.

Guillaume is still in holidays, so I don't think he will answer soon,
but I would like to hear what the others think

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

Graeme Rocher-4
+1 .. all of those are evil, evil things

Cheers

On Tue, May 24, 2011 at 5:43 PM, Jochen Theodorou <[hidden email]> wrote:

> Hi all,
>
> I intend to remove some features in Groovy 2 and would like to hear what you
> guys think of that.
>
> (1) automatic list expansion
>
> def foo(a,b){a+b}
> assert foo([1,2])==3
>
> The problem with this is for example vargs. if foo takes an Object[], then
> instead of mapping each element to elements of the array the list itself is
> the one and only element of that array. And if someone wants real fun, he
> can do an int[] and be surprised by a ClassCastException. On top of that we
> have spread expressions, which work perfectly well in all those cases.
>
> (2) String as char
>
> int i = "0"
> int j = "10"
>
> while the first one works, the second one will not. The background for this
> is, that "0" is handled as if it where a char, leading to a possible
> conversion to int based on the index value of the String/char. That cannot
> work for the j case, since this is a String not easily expressed as char. So
> we end up with a casting problem for that one. Luckily this conversion does
> not take part in method calls. I have no problem supporting
>
> char c="0"
>
> but I think the int/long/byte/short/double/float versions actually go a bit
> too far.
>
> (3) automatic null expansion
>
> def foo(x){x}
> assert foo()==null
>
> This was already mentioned by me several years ago, in which we had to keep
> it to keep SwingBuilder working. I think back then we didn't have an real
> optional "it" in Closures, requiring this trick play to go around the issue.
> But now we have optional values and I think there is no need for this
> version of method call logic beyond reason.... and that does not work with
> primitives as well of course.
>
> Guillaume is still in holidays, so I don't think he will answer soon, but I
> would like to hear what the others think
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead
> http://blackdragsview.blogspot.com/
> For Groovy programming sources visit http://groovy.codehaus.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>



--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

Wilson MacGyver
In reply to this post by Jochen Theodorou
agreed on all those as well. the first one messed me up a few times.

On Tue, May 24, 2011 at 11:43 AM, Jochen Theodorou <[hidden email]> wrote:

> Hi all,
>
> I intend to remove some features in Groovy 2 and would like to hear what you
> guys think of that.
>
> (1) automatic list expansion
>
> def foo(a,b){a+b}
> assert foo([1,2])==3
>
> The problem with this is for example vargs. if foo takes an Object[], then
> instead of mapping each element to elements of the array the list itself is
> the one and only element of that array. And if someone wants real fun, he
> can do an int[] and be surprised by a ClassCastException. On top of that we
> have spread expressions, which work perfectly well in all those cases.
>
> (2) String as char
>
> int i = "0"
> int j = "10"
>
> while the first one works, the second one will not. The background for this
> is, that "0" is handled as if it where a char, leading to a possible
> conversion to int based on the index value of the String/char. That cannot
> work for the j case, since this is a String not easily expressed as char. So
> we end up with a casting problem for that one. Luckily this conversion does
> not take part in method calls. I have no problem supporting
>
> char c="0"
>
> but I think the int/long/byte/short/double/float versions actually go a bit
> too far.
>
> (3) automatic null expansion
>
> def foo(x){x}
> assert foo()==null
>
> This was already mentioned by me several years ago, in which we had to keep
> it to keep SwingBuilder working. I think back then we didn't have an real
> optional "it" in Closures, requiring this trick play to go around the issue.
> But now we have optional values and I think there is no need for this
> version of method call logic beyond reason.... and that does not work with
> primitives as well of course.
>
> Guillaume is still in holidays, so I don't think he will answer soon, but I
> would like to hear what the others think
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead
> http://blackdragsview.blogspot.com/
> For Groovy programming sources visit http://groovy.codehaus.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>



--
Omnem crede diem tibi diluxisse supremum.

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

melix
In reply to this post by Graeme Rocher-4
+1 (and for the list expansion, the spread operator is little used so I
guess this feature is really useless).

Le 24/05/2011 20:29, Graeme Rocher a écrit :

> +1 .. all of those are evil, evil things
>
> Cheers
>
> On Tue, May 24, 2011 at 5:43 PM, Jochen Theodorou<[hidden email]>  wrote:
>> Hi all,
>>
>> I intend to remove some features in Groovy 2 and would like to hear what you
>> guys think of that.
>>
>> (1) automatic list expansion
>>
>> def foo(a,b){a+b}
>> assert foo([1,2])==3
>>
>> The problem with this is for example vargs. if foo takes an Object[], then
>> instead of mapping each element to elements of the array the list itself is
>> the one and only element of that array. And if someone wants real fun, he
>> can do an int[] and be surprised by a ClassCastException. On top of that we
>> have spread expressions, which work perfectly well in all those cases.
>>
>> (2) String as char
>>
>> int i = "0"
>> int j = "10"
>>
>> while the first one works, the second one will not. The background for this
>> is, that "0" is handled as if it where a char, leading to a possible
>> conversion to int based on the index value of the String/char. That cannot
>> work for the j case, since this is a String not easily expressed as char. So
>> we end up with a casting problem for that one. Luckily this conversion does
>> not take part in method calls. I have no problem supporting
>>
>> char c="0"
>>
>> but I think the int/long/byte/short/double/float versions actually go a bit
>> too far.
>>
>> (3) automatic null expansion
>>
>> def foo(x){x}
>> assert foo()==null
>>
>> This was already mentioned by me several years ago, in which we had to keep
>> it to keep SwingBuilder working. I think back then we didn't have an real
>> optional "it" in Closures, requiring this trick play to go around the issue.
>> But now we have optional values and I think there is no need for this
>> version of method call logic beyond reason.... and that does not work with
>> primitives as well of course.
>>
>> Guillaume is still in holidays, so I don't think he will answer soon, but I
>> would like to hear what the others think
>>
>> bye blackdrag
>>
>> --
>> Jochen "blackdrag" Theodorou
>> The Groovy Project Tech Lead
>> http://blackdragsview.blogspot.com/
>> For Groovy programming sources visit http://groovy.codehaus.org
>>
>>
>> ---------------------------------------------------------------------
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

Jochen Theodorou
In reply to this post by Jochen Theodorou
Am 24.05.2011 17:43, schrieb Jochen Theodorou:
> Hi all,
>
> I intend to remove some features in Groovy 2 and would like to hear what
> you guys think of that.
[...]

since the echo was so positive I consider those features as almost
removed for 2.0 ;)

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

Guillaume Laforge-4
In reply to this post by Jochen Theodorou
+1

On Tue, May 24, 2011 at 17:43, Jochen Theodorou <[hidden email]> wrote:
Hi all,

I intend to remove some features in Groovy 2 and would like to hear what you guys think of that.

(1) automatic list expansion

def foo(a,b){a+b}
assert foo([1,2])==3

The problem with this is for example vargs. if foo takes an Object[], then instead of mapping each element to elements of the array the list itself is the one and only element of that array. And if someone wants real fun, he can do an int[] and be surprised by a ClassCastException. On top of that we have spread expressions, which work perfectly well in all those cases.

(2) String as char

int i = "0"
int j = "10"

while the first one works, the second one will not. The background for this is, that "0" is handled as if it where a char, leading to a possible conversion to int based on the index value of the String/char. That cannot work for the j case, since this is a String not easily expressed as char. So we end up with a casting problem for that one. Luckily this conversion does not take part in method calls. I have no problem supporting

char c="0"

but I think the int/long/byte/short/double/float versions actually go a bit too far.

(3) automatic null expansion

def foo(x){x}
assert foo()==null

This was already mentioned by me several years ago, in which we had to keep it to keep SwingBuilder working. I think back then we didn't have an real optional "it" in Closures, requiring this trick play to go around the issue. But now we have optional values and I think there is no need for this version of method call logic beyond reason.... and that does not work with primitives as well of course.

Guillaume is still in holidays, so I don't think he will answer soon, but I would like to hear what the others think

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


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

  http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

Dierk König
In reply to this post by Jochen Theodorou
well, you should allow us a bit more time than a few hours for deciding on this :-)

cheers
Dierk

Am 24.05.2011 um 22:16 schrieb Jochen Theodorou:

> Am 24.05.2011 17:43, schrieb Jochen Theodorou:
>> Hi all,
>>
>> I intend to remove some features in Groovy 2 and would like to hear what
>> you guys think of that.
> [...]
>
> since the echo was so positive I consider those features as almost removed for 2.0 ;)
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead
> http://blackdragsview.blogspot.com/
> For Groovy programming sources visit http://groovy.codehaus.org
>
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

Jochen Theodorou
Am 24.05.2011 23:05, schrieb Dierk König:
> well, you should allow us a bit more time than a few hours for deciding on this :-)

ohhh ;)

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

Dierk König
In reply to this post by Jochen Theodorou
> (1) automatic list expansion

+1 for deletion

> (2) String as char

+1 for deletion

> (3) automatic null expansion
>
> def foo(x){x}
> assert foo()==null

This may need a bit more consideration.
a) since SwingBuilder needed the feature, other ones may do as well
b) there also is the issue of keeping closures and methods analogous for the caller, e.g.

def bar = { x -> x }
assert bar() == null

would still be allowed (?)

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: removing features in Groovy 2

Jon Cox
In reply to this post by Guillaume Laforge-4

 +!

 It all sounds great, particularly dropping
 auto list expansion.


 Out of curiosity, any chance of rationalizing
 getAt() versus function calls in Groovy 2?

 Back when GROOVY-3392 was filed, I floated the
 notion of a static rule making whitespace between
 foo and the leading '[' signify a function call
 with elided parens:
 
        foo 42      // function call:   foo(42);

        foo[42]     // indexing op:     foo.getAt(42);

        foo [42]    // current:         foo.getAt(42);
                    // __PROPOSED__:    foo([42]);

        foo([42])   // function call:   foo([42]);

 The same goes for map:

         foo [x:"fun"]  // seems like Groovy should call
                        // be able to call  foo([x:"fun"]);
                               


 The general response at the time seemed to be that:
       
      [1]  Yes, that it would be more consistent,
           and yes, it's nice that it's static... but ...
           
      [2]  Adopting the proposal means trading an old syntax
           bug for a new whitespace hack. Not ideal.

      [3]  While most code that uses the getAt operator []
           doesn't look like  "foo [expr]", changing it
           might mess some people up.   Hard to tell.

      [4]  There might be a better way to fix GROOVY-3392
           than a whitespace hack.  Let's wait and see.

 
 With all the stuff going into Groovy2, has the world shifted
 in such a way that a better solution is available?

 Any more thoughts on GROOVY-3392 ?


                Cheers,
                -Jon
 


> > Hi all,
> >
> > I intend to remove some features in Groovy 2 and would like to hear what
> > you guys think of that.
> >
> > (1) automatic list expansion
> >
> > def foo(a,b){a+b}
> > assert foo([1,2])==3
> >
> > The problem with this is for example vargs. if foo takes an Object[], then
> > instead of mapping each element to elements of the array the list itself is
> > the one and only element of that array. And if someone wants real fun, he
> > can do an int[] and be surprised by a ClassCastException. On top of that we
> > have spread expressions, which work perfectly well in all those cases.
> >
> > (2) String as char
> >
> > int i = "0"
> > int j = "10"
> >
> > while the first one works, the second one will not. The background for this
> > is, that "0" is handled as if it where a char, leading to a possible
> > conversion to int based on the index value of the String/char. That cannot
> > work for the j case, since this is a String not easily expressed as char. So
> > we end up with a casting problem for that one. Luckily this conversion does
> > not take part in method calls. I have no problem supporting
> >
> > char c="0"
> >
> > but I think the int/long/byte/short/double/float versions actually go a bit
> > too far.
> >
> > (3) automatic null expansion
> >
> > def foo(x){x}
> > assert foo()==null
> >
> > This was already mentioned by me several years ago, in which we had to keep
> > it to keep SwingBuilder working. I think back then we didn't have an real
> > optional "it" in Closures, requiring this trick play to go around the issue.
> > But now we have optional values and I think there is no need for this
> > version of method call logic beyond reason.... and that does not work with
> > primitives as well of course.
> >
> > Guillaume is still in holidays, so I don't think he will answer soon, but I
> > would like to hear what the others think
> >
> > bye blackdrag
> >
> > --
> > Jochen "blackdrag" Theodorou
> > The Groovy Project Tech Lead
> > http://blackdragsview.blogspot.com/
> > For Groovy programming sources visit http://groovy.codehaus.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >   http://xircles.codehaus.org/manage_email
> >
> >
> >
>
>
> --
> 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


1234 ... 8