Re: support of Java style arrays; or using Groovy arrays?

On 23 Feb 2005, at 07:07, John Rose wrote:
> I like the Groovy list notation very, very much; if things work out 
> for list notation to support arrays too, then that is a great win.
>
> As James says, common cases like {int[] myInts = [1,2,3]} can be 
> optimized at compile time to bytecodes indistinguishable from what a 
> Java compiler would emit.
> (Note:  I do mean that primitive type 'int' there.  I see no reason to 
> support only reference types.)
>
> Making lists auto-coerce into arrays allows the more flexible and 
> groovily-integrated lists to serve wherever an array value is needed.
> The automatic coercion makes all of James' examples fall out for free.

Agreed.

> On Feb 22, 2005, at 13:41, Guillaume Laforge wrote:
>
>> jastrachan@... wrote:
>>> Integer[] x = [1, 2, 3]
>>> def x = [1, 2, 3] as int[]
>>> methodCall( [1, 2, 3] as Integer[] )
>>> Customer[] customers = collection.findAll { it.location == 'UK }
>>
>> In that example, shouldn't the last line read:
>>
>> def customers =
>>     collection.findAll { it.location == 'UK } as Customer[]
>>
>> or:
>>
>> Customer[] customers =
>>     collection.findAll { it.location == 'UK } as Customer[]
>>
>> Otherwise, your last line would generate a class cast exception at 
>> runtime, wouldn't it?
>
> In the last case, the coercion can also be implicit.
> (Most coercions are implicit in Groovy, aren't they?  Anybody care to 
> round up and document the current set?)

We've been fairly careful to limit auto-coercions so far to mostly 
auto-boxing type issues and numbers (char<->int and int <-> long and 
the like). The only exception is GString <-> String where we try really 
hard to let GStrings be synonymous with Strings. Thats not to say we 
couldn't add more; we've just been a little wary of adding too many.

> Assigning to a statically typed variable {T v = x} should coerce to 
> that variable's type {T v = (x) as T} without any special request.

Yes that was my thoughts exactly. That  these two statements yield the 
same result

T v = x
def v = x as T

i.e. defining a static type has an implicit coercion. This coercion 
could fail. A smart Groovy IDE could maybe try catch bad coercions (if 
it knows the type of x it could ask the MetaClass if it can support the 
coercion to T).

> Same for coercing actuals to formals.  This will give us great 
> interoperability with all those pre-collections Java APIs that use 
> arrays.

Agreed

> To close the loop, there should also be some Groovy story about 
> converting arrays (from those Java APIs) back to lists, maybe 
> implicitly.

Yes. I'm thinking that lists and arrays should happily coerce into each 
other.

int[] x = [1, 2, 3]
List y = x

I wonder if that should also mean that we can invoke methods with 
lists/arrays interchangeably?

def foo(String[] whatnot) {
     println whatnot.length
}

def list = [1, 2, 3]
foo(list)

BTW was chatting with Dion the other day and he came up with a 
requirement for creating lists & maps using another implementation; 
e.g. a LinkedList. His idea was to use the same coercion...

def z = [1, 2, 3] as LinkedList

which could be a neat way to specify the exact list/map implementation 
to use? Again like the list->array coercion, the list->concrete list 
implementation coercion is easy to catch in the AST to do the right 
thing efficiently.

James
-------
http://radio.weblogs.com/0112098/