Hi --

On Tue, 11 Jan 2005, Robert Klemme wrote:

>>> "David A. Black" <dblack / wobblini.net> wrote
>>>
>> On Tue, 11 Jan 2005, itsme213 wrote:
>>>
>>>    [x,y] = obj
>>> is the same as
>>>    x = obj[0]
>>>    y = obj[1]
>>> So I ask obj to 'do' its [0], [1] right where I want it. Variables are
> bound
>>> to results.
>>
>> Hmmm...
>>
>>    irb(main):004:0> obj = [1,2]
>>    => [1, 2]
>>    irb(main):005:0> [x,y] = obj
>>    SyntaxError: compile error
>>
>> Or did you mean: x,y = obj ?  I don't think I'd characterize it as obj
>> "doing its [0], [1]".  You're not sending messages to obj -- not even
>> the message #[].  What happens in this scenario depends on assignment
>> semantics, not message semantics.
>
> I'd say methods are invoked:

Definitely, but I still wouldn't call it message semantics.

> Now I'm making things more complicated: generic Enumerables and Arrays are
> treated differently in this assignment context:
>
>>> a,b,c = [0,1,2,3,4]
...
>>> a,b,c = *[0,1,2,3,4]
...
>>> a,b,c = f
...
>>> a,b,c = *f
>
> For arrays the star is added implicitely while for generic enumerables
> it's not.  That's might be a reason to do away with this implicit
> behavior - at least for me.

I think it's inevitable that arrays are "special" in a lot of these
situations -- as wrappers for multiple arguments and return values, as
the "normalized" format for results from Enumerable operations like
select and map, and so on.  Unless that's somehow all completely
redesigned, I think it would be better to keep the * behavior
array-bound in that sense.


David

-- 
David A. Black
dblack / wobblini.net