"David A. Black" <dblack / wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.61.0501120420420.1017 / wobblini...
> 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.

Ah, ok.  I see (at least I think I do). :-)

> > 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.

Although I completely agree that Array is special in a lot of respects,
I'm still not fully convinced that it's good to have the different
behavior at this place.  OTOH, it's not too big an issue (at least for me)
and conservatism is always a good option as it's least likely to break
existing code. :-)

Thanks for clarifying!

Kind regards

    robert