Groovy 2.0 suggestion

classic Classic list List threaded Threaded
15 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Groovy 2.0 suggestion

Marc Palmer Local
       
Tuples are one thing, and I recall there are outstanding requests for  
this.

However, pairs are a very common element and are already used within  
groovy for Map population.

So my request is:

"Can we add pairs as a 1st class type concept in Groovy 2.0".

i.e. currently we can do:

def map = [x:y, p:q]

I would like to be able to do:

def pair = x:y

This would be type compatible with map entries, so:

def pair = x:y
def map = [pair, p:q]

assert map == [x:y, p:q]

def swap(def pair) {
    return pair.value:pair.key
}

assert swap(a:b) == b:a

I think this would be a nice language feature, and may help with  
things like the (world shattering?) swap() problem :)

Marc

~ ~ ~
Marc Palmer ([hidden email])
Consultant/Analyst
http://www.anyware.co.uk/

AnyWare Ltd.


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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.0 suggestion

Jochen Theodorou
Marc Palmer schrieb:
>    
> Tuples are one thing, and I recall there are outstanding requests for this.
>
> However, pairs are a very common element and are already used within
> groovy for Map population.
>
> So my request is:
>
> "Can we add pairs as a 1st class type concept in Groovy 2.0".

what is the usage? What about allowing pairs only on the left side? Ok,
that's not pairs then, but well.. something in that direction

> i.e. currently we can do:
>
> def map = [x:y, p:q]
>
> I would like to be able to do:
>
> def pair = x:y
>
> This would be type compatible with map entries, so:
>
> def pair = x:y
> def map = [pair, p:q]
 >

> assert map == [x:y, p:q]
>
> def swap(def pair) {
>    return pair.value:pair.key
> }
>
> assert swap(a:b) == b:a
>
> I think this would be a nice language feature, and may help with things
> like the (world shattering?) swap() problem :)

with my macro idea we can do

swap (a,b) or swap(a:b)

being swap a macro without pairs. There should be a better usage. I
still like the diea of:

a,b = b,a

or even:

a,b,c,d = a,2*b,d,c*a

and it can be very interesting in combination with lists:

a,b = [1,2]

assert a==1
assert b==2

a,b = [1,2,3]

assert a==1
assert b==[2,3]

well, ok, the last is no "must have".

bye blackdrag

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

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.0 suggestion

Marc Palmer Local

On 16 Jan 2007, at 12:29, Jochen Theodorou wrote:

> Marc Palmer schrieb:
>>     Tuples are one thing, and I recall there are outstanding  
>> requests for this.
>> However, pairs are a very common element and are already used  
>> within groovy for Map population.
>> So my request is:
>> "Can we add pairs as a 1st class type concept in Groovy 2.0".
>
> what is the usage? What about allowing pairs only on the left side?  
> Ok, that's not pairs then, but well.. something in that direction

as per my examples:

>
>> i.e. currently we can do:
>> def map = [x:y, p:q]
>> I would like to be able to do:
>> def pair = x:y
>> This would be type compatible with map entries, so:
>> def pair = x:y
>> def map = [pair, p:q]
> >
>> assert map == [x:y, p:q]
>> def swap(def pair) {
>>    return pair.value:pair.key
>> }
>> assert swap(a:b) == b:a
>> I think this would be a nice language feature, and may help with  
>> things like the (world shattering?) swap() problem :)
>
> with my macro idea we can do
>
> swap (a,b) or swap(a:b)

Swap was a happy side effect.

It's just that in grails for example we can write custom taglibs.  
Some of these need attributes of the form of a single name/value  
pair. We can take a one-entry Map or a 2-element List but then we  
need to handle all the boundary conditions for underflow and overflow  
of element numbers etc

Example:

<g:select noSelection="['NONE':'-Choose a value-']"/>

This as a Map works but is ugly because of the validation related to  
it. We have to assume a single element, which means we need to access  
the entrySet()/keySet() etc etc

<g:select noSelection="${'NONE':'-Choose a value-'}"/>

If we had x:y pair syntax in Groovy, which is consistent with the  
inline Map syntax in Groovy, as above, I think it would be much cleaner.

If the solution can integrate with tuple requirements, even better:

def x = a:b:c:d

...where x:y is a special "pair" case compatible with Map entries.

Marc


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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.0 suggestion

Jochen Theodorou
Marc Palmer schrieb:

>
> On 16 Jan 2007, at 12:29, Jochen Theodorou wrote:
>
>> Marc Palmer schrieb:
>>>     Tuples are one thing, and I recall there are outstanding requests
>>> for this.
>>> However, pairs are a very common element and are already used within
>>> groovy for Map population.
>>> So my request is:
>>> "Can we add pairs as a 1st class type concept in Groovy 2.0".
>>
>> what is the usage? What about allowing pairs only on the left side?
>> Ok, that's not pairs then, but well.. something in that direction
>
> as per my examples:

yes, but these are not enough for me to see the wide benefit. I see only
one reason to do that here atm and that is not to have the overhead of a
HashMap. If you forget about that, then all your examples are working
with maps:

>>> i.e. currently we can do:
>>> def map = [x:y, p:q]
>>> I would like to be able to do:
>>> def pair = x:y

def pair = [(x):y]

>>> This would be type compatible with map entries, so:
>>> def pair = x:y
>>> def map = [pair, p:q]

def pair = [(x):y]
def map = [*pair, p:q)

>>> assert map == [x:y, p:q]
>>> def swap(def pair) {
>>>    return pair.value:pair.key
>>> }
>>> assert swap(a:b) == b:a

when you think about it... what is it you are swapping here? Yes, the
pait, but not the variables used for the pair. Not if we follow
call-by-copy-reference. We ahve reference logic in Groovy, but it is
normally not exposed. We have to do that then or it won't work. Besides
that your swap code has only read operations on pair, so pair will not
be changed, nor the referenced variables. instead a new pair objec will
be created where key and value are switched. But the original values are
the same, just the mapping is changed. Besides that we have a clush with
the current named parameter syntax here. swap(a:b) would normally call
swap with a Map with a key "a" (String) and a value b (whatever).

I am not saying this is useless crap, I just don't see where it will
help and how groovy people will benefit from it.

[...]

> It's just that in grails for example we can write custom taglibs. Some
> of these need attributes of the form of a single name/value pair. We can
> take a one-entry Map or a 2-element List but then we need to handle all
> the boundary conditions for underflow and overflow of element numbers etc
>
> Example:
>
> <g:select noSelection="['NONE':'-Choose a value-']"/>
>
> This as a Map works but is ugly because of the validation related to it.
> We have to assume a single element, which means we need to access the
> entrySet()/keySet() etc etc
>
> <g:select noSelection="${'NONE':'-Choose a value-'}"/>
>
> If we had x:y pair syntax in Groovy, which is consistent with the inline
> Map syntax in Groovy, as above, I think it would be much cleaner.

Is somthing like

<g:select noSelection="['NONE':'-Choose a value-'] as OneElementMap"/>

too long? Anyway the other syntax I showed might solve that problem too,
It would then be:

<g:select noSelection="'NONE','-Choose a value-'"/>

the nice thing  about

a,b = b,a

is that you don't need reference logic at all. But I am not sure that
using that as map is a good idea...

> If the solution can integrate with tuple requirements, even better:
>
> def x = a:b:c:d
>
> ...where x:y is a special "pair" case compatible with Map entries.

ehm... yes... or no? Sorry, I can't follow

bye blackdrag

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

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.0 suggestion

Martin C. Martin-2
A way to assign to multiple local variables is handy when you want to
return multiple values from a function.  For example:

def foo() {
    return [avalue, aname, amsg]
}

Right now you need to write:

temp = foo()
myvalue = temp[0]
myname = temp[1]
mymsg = temp[2]

Which is a lot of verbosity.  Alternately, you can just use temp[0]
wherever you'd use myvalue, but that's not as readable.  It would be
very handy to be able to write something like:

[myvalue, myname, mymsg] = foo()

Best,
Martin

Jochen Theodorou wrote:

> Marc Palmer schrieb:
>>
>> On 16 Jan 2007, at 12:29, Jochen Theodorou wrote:
>>
>>> Marc Palmer schrieb:
>>>>     Tuples are one thing, and I recall there are outstanding
>>>> requests for this.
>>>> However, pairs are a very common element and are already used within
>>>> groovy for Map population.
>>>> So my request is:
>>>> "Can we add pairs as a 1st class type concept in Groovy 2.0".
>>>
>>> what is the usage? What about allowing pairs only on the left side?
>>> Ok, that's not pairs then, but well.. something in that direction
>>
>> as per my examples:
>
> yes, but these are not enough for me to see the wide benefit. I see only
> one reason to do that here atm and that is not to have the overhead of a
> HashMap. If you forget about that, then all your examples are working
> with maps:
>
>>>> i.e. currently we can do:
>>>> def map = [x:y, p:q]
>>>> I would like to be able to do:
>>>> def pair = x:y
>
> def pair = [(x):y]
>
>>>> This would be type compatible with map entries, so:
>>>> def pair = x:y
>>>> def map = [pair, p:q]
>
> def pair = [(x):y]
> def map = [*pair, p:q)
>
>>>> assert map == [x:y, p:q]
>>>> def swap(def pair) {
>>>>    return pair.value:pair.key
>>>> }
>>>> assert swap(a:b) == b:a
>
> when you think about it... what is it you are swapping here? Yes, the
> pait, but not the variables used for the pair. Not if we follow
> call-by-copy-reference. We ahve reference logic in Groovy, but it is
> normally not exposed. We have to do that then or it won't work. Besides
> that your swap code has only read operations on pair, so pair will not
> be changed, nor the referenced variables. instead a new pair objec will
> be created where key and value are switched. But the original values are
> the same, just the mapping is changed. Besides that we have a clush with
> the current named parameter syntax here. swap(a:b) would normally call
> swap with a Map with a key "a" (String) and a value b (whatever).
>
> I am not saying this is useless crap, I just don't see where it will
> help and how groovy people will benefit from it.
>
> [...]
>> It's just that in grails for example we can write custom taglibs. Some
>> of these need attributes of the form of a single name/value pair. We
>> can take a one-entry Map or a 2-element List but then we need to
>> handle all the boundary conditions for underflow and overflow of
>> element numbers etc
>>
>> Example:
>>
>> <g:select noSelection="['NONE':'-Choose a value-']"/>
>>
>> This as a Map works but is ugly because of the validation related to
>> it. We have to assume a single element, which means we need to access
>> the entrySet()/keySet() etc etc
>>
>> <g:select noSelection="${'NONE':'-Choose a value-'}"/>
>>
>> If we had x:y pair syntax in Groovy, which is consistent with the
>> inline Map syntax in Groovy, as above, I think it would be much cleaner.
>
> Is somthing like
>
> <g:select noSelection="['NONE':'-Choose a value-'] as OneElementMap"/>
>
> too long? Anyway the other syntax I showed might solve that problem too,
> It would then be:
>
> <g:select noSelection="'NONE','-Choose a value-'"/>
>
> the nice thing  about
>
> a,b = b,a
>
> is that you don't need reference logic at all. But I am not sure that
> using that as map is a good idea...
>
>> If the solution can integrate with tuple requirements, even better:
>>
>> def x = a:b:c:d
>>
>> ...where x:y is a special "pair" case compatible with Map entries.
>
> ehm... yes... or no? Sorry, I can't follow
>
> bye blackdrag
>

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.0 suggestion

Guillaume Laforge
Administrator
I'd even go as far as suggesting:

def foo() { [4, "Guillaume", "hello"] }

def myValue, myName, myMsg = foo()

On 1/16/07, Martin C. Martin <[hidden email]> wrote:

> A way to assign to multiple local variables is handy when you want to
> return multiple values from a function.  For example:
>
> def foo() {
>     return [avalue, aname, amsg]
> }
>
> Right now you need to write:
>
> temp = foo()
> myvalue = temp[0]
> myname = temp[1]
> mymsg = temp[2]
>
> Which is a lot of verbosity.  Alternately, you can just use temp[0]
> wherever you'd use myvalue, but that's not as readable.  It would be
> very handy to be able to write something like:
>
> [myvalue, myname, mymsg] = foo()
>
> Best,
> Martin
>
> Jochen Theodorou wrote:
> > Marc Palmer schrieb:
> >>
> >> On 16 Jan 2007, at 12:29, Jochen Theodorou wrote:
> >>
> >>> Marc Palmer schrieb:
> >>>>     Tuples are one thing, and I recall there are outstanding
> >>>> requests for this.
> >>>> However, pairs are a very common element and are already used within
> >>>> groovy for Map population.
> >>>> So my request is:
> >>>> "Can we add pairs as a 1st class type concept in Groovy 2.0".
> >>>
> >>> what is the usage? What about allowing pairs only on the left side?
> >>> Ok, that's not pairs then, but well.. something in that direction
> >>
> >> as per my examples:
> >
> > yes, but these are not enough for me to see the wide benefit. I see only
> > one reason to do that here atm and that is not to have the overhead of a
> > HashMap. If you forget about that, then all your examples are working
> > with maps:
> >
> >>>> i.e. currently we can do:
> >>>> def map = [x:y, p:q]
> >>>> I would like to be able to do:
> >>>> def pair = x:y
> >
> > def pair = [(x):y]
> >
> >>>> This would be type compatible with map entries, so:
> >>>> def pair = x:y
> >>>> def map = [pair, p:q]
> >
> > def pair = [(x):y]
> > def map = [*pair, p:q)
> >
> >>>> assert map == [x:y, p:q]
> >>>> def swap(def pair) {
> >>>>    return pair.value:pair.key
> >>>> }
> >>>> assert swap(a:b) == b:a
> >
> > when you think about it... what is it you are swapping here? Yes, the
> > pait, but not the variables used for the pair. Not if we follow
> > call-by-copy-reference. We ahve reference logic in Groovy, but it is
> > normally not exposed. We have to do that then or it won't work. Besides
> > that your swap code has only read operations on pair, so pair will not
> > be changed, nor the referenced variables. instead a new pair objec will
> > be created where key and value are switched. But the original values are
> > the same, just the mapping is changed. Besides that we have a clush with
> > the current named parameter syntax here. swap(a:b) would normally call
> > swap with a Map with a key "a" (String) and a value b (whatever).
> >
> > I am not saying this is useless crap, I just don't see where it will
> > help and how groovy people will benefit from it.
> >
> > [...]
> >> It's just that in grails for example we can write custom taglibs. Some
> >> of these need attributes of the form of a single name/value pair. We
> >> can take a one-entry Map or a 2-element List but then we need to
> >> handle all the boundary conditions for underflow and overflow of
> >> element numbers etc
> >>
> >> Example:
> >>
> >> <g:select noSelection="['NONE':'-Choose a value-']"/>
> >>
> >> This as a Map works but is ugly because of the validation related to
> >> it. We have to assume a single element, which means we need to access
> >> the entrySet()/keySet() etc etc
> >>
> >> <g:select noSelection="${'NONE':'-Choose a value-'}"/>
> >>
> >> If we had x:y pair syntax in Groovy, which is consistent with the
> >> inline Map syntax in Groovy, as above, I think it would be much cleaner.
> >
> > Is somthing like
> >
> > <g:select noSelection="['NONE':'-Choose a value-'] as OneElementMap"/>
> >
> > too long? Anyway the other syntax I showed might solve that problem too,
> > It would then be:
> >
> > <g:select noSelection="'NONE','-Choose a value-'"/>
> >
> > the nice thing  about
> >
> > a,b = b,a
> >
> > is that you don't need reference logic at all. But I am not sure that
> > using that as map is a good idea...
> >
> >> If the solution can integrate with tuple requirements, even better:
> >>
> >> def x = a:b:c:d
> >>
> >> ...where x:y is a special "pair" case compatible with Map entries.
> >
> > ehm... yes... or no? Sorry, I can't follow
> >
> > bye blackdrag
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.0 suggestion

Alex Popescu
On 1/16/07, Guillaume Laforge <[hidden email]> wrote:
> I'd even go as far as suggesting:
>
> def foo() { [4, "Guillaume", "hello"] }
>
> def myValue, myName, myMsg = foo()
>

I am not sure I got the discussion about pairs (is this concept
available anywhere except Lisp?) and tuples, but I would definitely
like to see the above working :-).

./alex
--
.w( the_mindstorm )p.

> On 1/16/07, Martin C. Martin <[hidden email]> wrote:
> > A way to assign to multiple local variables is handy when you want to
> > return multiple values from a function.  For example:
> >
> > def foo() {
> >     return [avalue, aname, amsg]
> > }
> >
> > Right now you need to write:
> >
> > temp = foo()
> > myvalue = temp[0]
> > myname = temp[1]
> > mymsg = temp[2]
> >
> > Which is a lot of verbosity.  Alternately, you can just use temp[0]
> > wherever you'd use myvalue, but that's not as readable.  It would be
> > very handy to be able to write something like:
> >
> > [myvalue, myname, mymsg] = foo()
> >
> > Best,
> > Martin
> >
> > Jochen Theodorou wrote:
> > > Marc Palmer schrieb:
> > >>
> > >> On 16 Jan 2007, at 12:29, Jochen Theodorou wrote:
> > >>
> > >>> Marc Palmer schrieb:
> > >>>>     Tuples are one thing, and I recall there are outstanding
> > >>>> requests for this.
> > >>>> However, pairs are a very common element and are already used within
> > >>>> groovy for Map population.
> > >>>> So my request is:
> > >>>> "Can we add pairs as a 1st class type concept in Groovy 2.0".
> > >>>
> > >>> what is the usage? What about allowing pairs only on the left side?
> > >>> Ok, that's not pairs then, but well.. something in that direction
> > >>
> > >> as per my examples:
> > >
> > > yes, but these are not enough for me to see the wide benefit. I see only
> > > one reason to do that here atm and that is not to have the overhead of a
> > > HashMap. If you forget about that, then all your examples are working
> > > with maps:
> > >
> > >>>> i.e. currently we can do:
> > >>>> def map = [x:y, p:q]
> > >>>> I would like to be able to do:
> > >>>> def pair = x:y
> > >
> > > def pair = [(x):y]
> > >
> > >>>> This would be type compatible with map entries, so:
> > >>>> def pair = x:y
> > >>>> def map = [pair, p:q]
> > >
> > > def pair = [(x):y]
> > > def map = [*pair, p:q)
> > >
> > >>>> assert map == [x:y, p:q]
> > >>>> def swap(def pair) {
> > >>>>    return pair.value:pair.key
> > >>>> }
> > >>>> assert swap(a:b) == b:a
> > >
> > > when you think about it... what is it you are swapping here? Yes, the
> > > pait, but not the variables used for the pair. Not if we follow
> > > call-by-copy-reference. We ahve reference logic in Groovy, but it is
> > > normally not exposed. We have to do that then or it won't work. Besides
> > > that your swap code has only read operations on pair, so pair will not
> > > be changed, nor the referenced variables. instead a new pair objec will
> > > be created where key and value are switched. But the original values are
> > > the same, just the mapping is changed. Besides that we have a clush with
> > > the current named parameter syntax here. swap(a:b) would normally call
> > > swap with a Map with a key "a" (String) and a value b (whatever).
> > >
> > > I am not saying this is useless crap, I just don't see where it will
> > > help and how groovy people will benefit from it.
> > >
> > > [...]
> > >> It's just that in grails for example we can write custom taglibs. Some
> > >> of these need attributes of the form of a single name/value pair. We
> > >> can take a one-entry Map or a 2-element List but then we need to
> > >> handle all the boundary conditions for underflow and overflow of
> > >> element numbers etc
> > >>
> > >> Example:
> > >>
> > >> <g:select noSelection="['NONE':'-Choose a value-']"/>
> > >>
> > >> This as a Map works but is ugly because of the validation related to
> > >> it. We have to assume a single element, which means we need to access
> > >> the entrySet()/keySet() etc etc
> > >>
> > >> <g:select noSelection="${'NONE':'-Choose a value-'}"/>
> > >>
> > >> If we had x:y pair syntax in Groovy, which is consistent with the
> > >> inline Map syntax in Groovy, as above, I think it would be much cleaner.
> > >
> > > Is somthing like
> > >
> > > <g:select noSelection="['NONE':'-Choose a value-'] as OneElementMap"/>
> > >
> > > too long? Anyway the other syntax I showed might solve that problem too,
> > > It would then be:
> > >
> > > <g:select noSelection="'NONE','-Choose a value-'"/>
> > >
> > > the nice thing  about
> > >
> > > a,b = b,a
> > >
> > > is that you don't need reference logic at all. But I am not sure that
> > > using that as map is a good idea...
> > >
> > >> If the solution can integrate with tuple requirements, even better:
> > >>
> > >> def x = a:b:c:d
> > >>
> > >> ...where x:y is a special "pair" case compatible with Map entries.
> > >
> > > ehm... yes... or no? Sorry, I can't follow
> > >
> > > bye blackdrag
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> http://glaforge.free.fr/blog/groovy
>
> ---------------------------------------------------------------------
> 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: Groovy 2.0 suggestion

Guillaume Laforge
Administrator
On 1/16/07, Alexandru Popescu <[hidden email]> wrote:

> On 1/16/07, Guillaume Laforge <[hidden email]> wrote:
> > I'd even go as far as suggesting:
> >
> > def foo() { [4, "Guillaume", "hello"] }
> >
> > def myValue, myName, myMsg = foo()
> >
>
> I am not sure I got the discussion about pairs (is this concept
> available anywhere except Lisp?) and tuples, but I would definitely
> like to see the above working :-).

I'm sure I've seen that elsewhere... but don't recall where :-)
It's interesting for the "swap" use case:

a, b = [b, a]

But ideally this one would be even nicer :

a, b = b, a

:-)

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.0 suggestion

Marc Palmer Local
In reply to this post by Jochen Theodorou
>
>>>> i.e. currently we can do:
>>>> def map = [x:y, p:q]
>>>> I would like to be able to do:
>>>> def pair = x:y
>
> def pair = [(x):y]
>
>>>> This would be type compatible with map entries, so:
>>>> def pair = x:y
>>>> def map = [pair, p:q]
>
> def pair = [(x):y]
> def map = [*pair, p:q)
>

Syntactically obscure to me...

[snip]

>> If the solution can integrate with tuple requirements, even better:
>> def x = a:b:c:d
>> ...where x:y is a special "pair" case compatible with Map entries.
>
> ehm... yes... or no? Sorry, I can't follow
>

OK sorry if I'm not being clear.

Currently we can do:

def myMap = ['firstName' : 'Marc', 'lastName' : 'Palmer']

This is, under the hood, indirectly creating two Map "Entry" objects.  
So what I am saying is that we already have a syntax for creation of  
"Entry" pairs - namely the "<key>:<value>" construct.

So by extrapolating that I feel that if we are to have tuples or  
pairs etc they should draw on the already existing unambiguous  
syntax. i.e: to recode the above:

def entry1 = 'firstName' : 'Marc'
def entry2 = 'lastName' : 'Palmer'
def myMap = [entry1, entry2]

Now I can already see problems with the above, as myMap would  
(without some instanceof magic) create a list containing two "pair"  
objects. However this could be overcome I think. This is useful  
because it is very often we use pairs in development - to say it is  
not useful is to say that 2-element tuples are not useful - they are  
an identical concept I believe.

It could also mean that we could augment Map to allow you to extract  
these pairs:

def myPair = myMap.getEntry('firstName')

...as well as allowing:

myMap.put( entry2)

It basically makes it possible (and safe) to pass name/value pairs  
around between Maps and other code. I imagine you can't safely do  
this with Entry(s) that are managed by the "owning" Map.

I think the above would be useful and should be possible because it  
is merely a natural progression of what already exists in the  
language - not a single new syntax or operator to think about.

Then I offered, not being somebody who has programmed with tuples at  
all, that you could take this existing language construct and apply  
it to objects with N "parts" (tuples):

def vector1 =  1.0 : 0 : 1.0 : 0

There may well be real problems with parsing this stuff, where parens  
would be required when passing "tuples" as values/keys in a map for  
example.

However I think there is a lot of value in leveraging an existing  
language construct, which is effectively used to create 2-element  
tuples already when constructing Maps.

Marc


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

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.0 suggestion

Alex Shneyderman
In reply to this post by Alex Popescu
> I am not sure I got the discussion about pairs (is this concept
> available anywhere except Lisp?) and tuples, but I would definitely
> like to see the above working :-).

tuples do exist in python as frist class citizens :-)
http://www.python.org/doc/1.5.1p1/tut/tuples.html

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

    http://xircles.codehaus.org/manage_email

12