23 Feb 2005 20:35
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
exception
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.
James
-------
http://radio.weblogs.com/0112098/
RSS Feed