Feb 22
One of my minor pet peeves with Groovy has been:
# simple list
def x = [1, 2, "three"]# another type of list
def x = new LinkedList()
x << 1
...
And it is also annoying to have a different way to setup a Java Array:
int x = new int[] { …. }
Why not unify this? Groovy is good about consistency, and trying to unify the models, so now maybe we will get there via:
def x = [1, 2, 3] as LinkedList
def x = [1, 2, 3] as int[]
def aMap = ['name':'value', 'n2':'val2'] as TreeMap
Much cleaner!
Emmanuel Pirsch also had a good idea of using casting:
int[] x= [1, 2, 3]
x= (int[]) [1, 2, 3]
x= (TreeMap) ["name" : name, "value" : value]
February 22nd, 2005 at 12:03 pm
Why not :
def int[] x= [1, 2, 3];
I believe it would make more sense than adding another keyword.
And if you do not want strong typing, then you would probably do not care if it is an array or a List (you can use each() on both).
February 22nd, 2005 at 12:03 pm
Why not :
def int[] x= [1, 2, 3];
I believe it would make more sense than adding another keyword.
And if you do not want strong typing, then you would probably do not care if it is an array or a List (you can use each() on both).
February 22nd, 2005 at 12:11 pm
Hi Emmanuel -
int[] x = [1, 2, 3]
works great too…. for the Array case.
I like the ‘as’ for chosing types of lists and maps.
“I want a list, oh and use this type for me will you?”
“I want a list, oh and use an arry will you?”
February 22nd, 2005 at 12:11 pm
Hi Emmanuel -
int[] x = [1, 2, 3]
works great too…. for the Array case.
I like the ‘as’ for chosing types of lists and maps.
“I want a list, oh and use this type for me will you?”
“I want a list, oh and use an arry will you?”
February 22nd, 2005 at 12:40 pm
Yes, that would be nice. But, unless we use an implementation class (instead of an interface), it would add more complexity to the compiler. The compiler will now have to choose an implementation for SortableMap (or should it be SortedMap).
I think that either strong typing or casting could be used so I could say :
int[] x= [1, 2, 3]
x= (int[]) [1, 2, 3]
x= (TreeMap) ["name" : name, "value" : value]
The first two case should work a bit like autoboxing. The third case would be like creating a new instance of the TreeMap class and then adding the entries.
February 22nd, 2005 at 12:40 pm
Yes, that would be nice. But, unless we use an implementation class (instead of an interface), it would add more complexity to the compiler. The compiler will now have to choose an implementation for SortableMap (or should it be SortedMap).
I think that either strong typing or casting could be used so I could say :
int[] x= [1, 2, 3]
x= (int[]) [1, 2, 3]
x= (TreeMap) ["name" : name, "value" : value]
The first two case should work a bit like autoboxing. The third case would be like creating a new instance of the TreeMap class and then adding the entries.
February 22nd, 2005 at 2:08 pm
In most Groovy code this is a “don’t care” sort of item – you shouldn’t care whether you have an array or a List, and generally a list will do just fine. This becomes an issue mostly when you’re calling into Java code – in which case I agree with Emmanuel. This is really a question of auto-boxing – you’ve got a list and want to pass it to a Java method taking “int[]” or whatever. Or you’ve got an array and need to pass it into a List. In this case Groovy should auto-convert for you and throw an exception at runtime if your list isn’t homogenous and compatible with the target array. Going from array to list is trivially, and given that it’s scripting no one cares what the List implementation is.
Of course this is all a red herring – “as” isn’t proposed here to fix the array problem per se. The real reason for “as” is because some Groovy people thought it’d be neat to get rid of Java style casts and invent a new cast syntax. That’s what “as” here, and the Groovy guys are merely trying to apply “as” to the arrayList problem.
February 22nd, 2005 at 2:08 pm
In most Groovy code this is a “don’t care” sort of item – you shouldn’t care whether you have an array or a List, and generally a list will do just fine. This becomes an issue mostly when you’re calling into Java code – in which case I agree with Emmanuel. This is really a question of auto-boxing – you’ve got a list and want to pass it to a Java method taking “int[]” or whatever. Or you’ve got an array and need to pass it into a List. In this case Groovy should auto-convert for you and throw an exception at runtime if your list isn’t homogenous and compatible with the target array. Going from array to list is trivially, and given that it’s scripting no one cares what the List implementation is.
Of course this is all a red herring – “as” isn’t proposed here to fix the array problem per se. The real reason for “as” is because some Groovy people thought it’d be neat to get rid of Java style casts and invent a new cast syntax. That’s what “as” here, and the Groovy guys are merely trying to apply “as” to the arrayList problem.
February 22nd, 2005 at 2:32 pm
Dion,
It’s not that I’m offended… But you managed to make typos on both my first and last name. Now… I’m used to people making typos with my last name. But both at the same time… You’re the king ;-)
February 22nd, 2005 at 2:32 pm
Dion,
It’s not that I’m offended… But you managed to make typos on both my first and last name. Now… I’m used to people making typos with my last name. But both at the same time… You’re the king ;-)
February 24th, 2005 at 12:24 am
Mike
‘as’ is different from a Java cast currently in that ‘as’ forces a smart coercion. Casting remains the same as Java (in that it could barf and doesn’t do anything clever).
James
February 24th, 2005 at 12:24 am
Mike
‘as’ is different from a Java cast currently in that ‘as’ forces a smart coercion. Casting remains the same as Java (in that it could barf and doesn’t do anything clever).
James