jastrachan | 23 Feb 20:35 2005

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

On 23 Feb 2005, at 11:42, Guillaume Laforge wrote:

>>>> 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.
> I like the idea of auto-coercion. But when we're in
> statically-typed-mode, shouldn't we get compiler errors if we don't
> use the coercion explicitely? The idea of static typing in Groovy was
> to allow the user to catch errors or typos more quickly. Whereas
> dynamic typing allows him to be more productive duck-typing-wise :-)
> So, shouldn't we issue compiler errors? or perhaps warnings at least?
> If we'd want the coercion, we should force it with 'as'.

In general yes - but I think arrays and lists could be an obvious 

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

seems reasonable. e.g. Java allows

int[] x = {1, 2, 3}

so I think the explicit coercion for lists & arrays in static type mode 
seems a little noisy.