assigning a non array value to an array

[Jochen Theodorou]

Hi,

No I am not making a proposal, I am asking if that is really ok!

What we allow is doing something like

String args = "101"
args = 1
assert args.class == Integer

a Java programmer would surely question thins like that. But anyway,
what I question is that the type is kept if it is an array. not only can
we do:

String[] args = "101"

which is quite handy to split a String in characters, we also allow

int[] args = 1

which makes an int[] of length 1. Ok, why not... but..

int[] args = "101"

is a bit much. I think we should either forbid the assignment with a
incompatible type like in the first example, or remove all that array
init stuff here. We can still have the array stuff with the "as" syntax,
if we decide not to allow them in normal casrs. But the current
situation is bit surprising I think. Or does someone have a logic (in
matters of semantics and syntax) exlpanation why this should be kept
that way?

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead
http://blackdragsview.blogspot.com/

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

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 28 Aug 2006, at 14:33, Jochen Theodorou wrote:

> Hi,
>
> No I am not making a proposal, I am asking if that is really ok!
>
> What we allow is doing something like
>
> String args = "101"
> args = 1
> assert args.class == Integer

This is surely a bug - the compiler should object to the second  
assignment shouldn't it?

>
> a Java programmer would surely question thins like that. But  
> anyway, what I question is that the type is kept if it is an array.  
> not only can we do:
>
> String[] args = "101"
>
> which is quite handy to split a String in characters, we also allow
>
> int[] args = 1
>
> which makes an int[] of length 1. Ok, why not... but..

if the sacond assignment results in a single element array then so  
should the first.

arguably

char[] args = "101"

should give you an array of three chars

>
> int[] args = "101"
>
> is a bit much. I think we should either forbid the assignment with  
> a incompatible type like in the first example, or remove all that  
> array init stuff here. We can still have the array stuff with the  
> "as" syntax, if we decide not to allow them in normal casrs. But  
> the current situation is bit surprising I think. Or does someone  
> have a logic (in matters of semantics and syntax) exlpanation why  
> this should be kept that way?
>

I agree that this should not be allowed:)


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:

>
> On 28 Aug 2006, at 14:33, Jochen Theodorou wrote:
>
>> Hi,
>>
>> No I am not making a proposal, I am asking if that is really ok!
>>
>> What we allow is doing something like
>>
>> String args = "101"
>> args = 1
>> assert args.class == Integer
>
> This is surely a bug - the compiler should object to the second
> assignment shouldn't it?

It seems that this here is less surprising than the behaviour with arrays.

>> a Java programmer would surely question thins like that. But anyway,
>> what I question is that the type is kept if it is an array. not only
>> can we do:
>>
>> String[] args = "101"
>>
>> which is quite handy to split a String in characters, we also allow
>>
>> int[] args = 1
>>
>> which makes an int[] of length 1. Ok, why not... but..
>
> if the sacond assignment results in a single element array then so
> should the first.
>
> arguably
>
> char[] args = "101"
>
> should give you an array of three chars

well, it comes all from Invoker#asType or to be more correct from
asCollection in the same class sued by asType. asCollection is used for
our for-loop too. I have to dig in, but I hope they are sperated enough
here. Anyway, remember that in Groovy a char is a string of size 1. So
it is perfectly legal to make "101" into a 3 element array. This all
come form the formerly nonexisting seperation between a normal cast and
the as-syntax I think. I mean:

args = "101" as String[]

would look much more logical, even

args = "101" as int[]

I started to seperate them, but they are all still basing on asType from
InvokerHelper and thus making the same actions for a normal (implicit or
explicit) cast and for the as-syntax.

You see, if a one element String is a char, and a char is a int...
anyway that would mean a transformation over two edges, nothing for a
normal cast I think. So my proposal here is to not allow the int[]
version, to allow the char[] version, to not allow the current String[]
version, but to make it a one lement array in that case and to not allow
this foreign type assingment in the first example.

that is ok for you?


bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead
http://blackdragsview.blogspot.com/

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

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 28 Aug 2006, at 15:40, Jochen Theodorou wrote:

> John Wilson schrieb:
>> On 28 Aug 2006, at 14:33, Jochen Theodorou wrote:
>>> Hi,
>>>
>>> No I am not making a proposal, I am asking if that is really ok!
>>>
>>> What we allow is doing something like
>>>
>>> String args = "101"
>>> args = 1
>>> assert args.class == Integer
>> This is surely a bug - the compiler should object to the second  
>> assignment shouldn't it?
>
> It seems that this here is less surprising than the behaviour with  
> arrays.

It seems only to be the behaviour if the variable is local:

class MyClass {
     public int i
}

def c = new MyClass()
c.i = 0
c.i = "hello"

gives

Caught: groovy.lang.TypeMismatchException: 'MyClass.i' can not refer  
to the value 'hello' (type java.lang.String), because it is of the  
type int
groovy.lang.TypeMismatchException: 'MyClass.i' can not refer to the  
value 'hello' (type java.lang.String), because it is of the type int

Nice error message!

>
>>> a Java programmer would surely question thins like that. But  
>>> anyway, what I question is that the type is kept if it is an  
>>> array. not only can we do:
>>>
>>> String[] args = "101"
>>>
>>> which is quite handy to split a String in characters, we also allow
>>>
>>> int[] args = 1
>>>
>>> which makes an int[] of length 1. Ok, why not... but..
>> if the sacond assignment results in a single element array then so  
>> should the first.
>> arguably
>> char[] args = "101"
>> should give you an array of three chars
>
> well, it comes all from Invoker#asType or to be more correct from  
> asCollection in the same class sued by asType. asCollection is used  
> for our for-loop too. I have to dig in, but I hope they are  
> sperated enough here. Anyway, remember that in Groovy a char is a  
> string of size 1. So it is perfectly legal to make "101" into a 3  
> element array. This all come form the formerly nonexisting  
> seperation between a normal cast and the as-syntax I think. I mean:
>
> args = "101" as String[]
>
> would look much more logical, even
>
> args = "101" as int[]
>
> I started to seperate them, but they are all still basing on asType  
> from InvokerHelper and thus making the same actions for a normal  
> (implicit or explicit) cast and for the as-syntax.
>
> You see, if a one element String is a char, and a char is a int...  
> anyway that would mean a transformation over two edges, nothing for  
> a normal cast I think. So my proposal here is to not allow the int
> [] version, to allow the char[] version, to not allow the current  
> String[] version, but to make it a one lement array in that case  
> and to not allow this foreign type assingment in the first example.
>
> that is ok for you?

Seems OK

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email