From: Robert Klemme <bob.news@...>
Date: 2005-01-10T18:31:21+09:00
Subject: Re: multiple values & variable assignment


"itsme213" <itsme213@hotmail.com> schrieb im Newsbeitrag
news:sskEd.20122$q4.3165@fe1.texas.rr.com...
> But this is about more than just assignment, it is also about method
calls
> vs. method defs.
>
> "Robert Klemme" <bob.news@gmx.net> wrote
>
> > > Why does
> > >    def f; 1, 2, 3; end
> >
> > You sure, that this is the code you use?
>
> My mistake, it was: def f; return 1, 2, 3; end
>
> > It's an optimization to save typing: if there are multiple values and
on
> one
> > side there is only one value "*" is automatically prepended:
>
> Ah. Unfortunate decision, because ...
>
> x = 1, 2, 3 #=> x = [1, 2, 3]
> *x = 1, 2, 3 #=> x = [1, 2, 3]
>
> def f(x); puts x; end
>     f(1, 2, 3) #=> ArgError: wrong num. of args
>     f([1, 2, 3]) #=> [1, 2, 3]
>
> def g(*x); puts x; end
>     g(1, 2, 3) #=> [1, 2, 3]
>
> > >> x, = f
>
> Ouch! I did not know that.  But
>     def f(x,); end #=> error.
> i.e. There is no such ',' syntax for method or proc parameters, just
'*'.

Yeah:

>> def f(x,*) p x end
=> nil
>> f 1,2,3
1
=> nil

> Method calls establish bindings. *, **, and & are nicely consistent and
> symmetric in
>     method call: ... f(*x)
>         vs.
>     method definition: def f(*x); end
> Since both method call and assignment establish variable bindings, I
would
> suggest that:
> * on lhs vs. rhs of assignement should parallel * on call vs. def
> ** on lhs vs. rhs of assignment (if allowed) should parallel ** on call
vs.
> def

I think "**" is already taken:

>> -2 ** 3
=> -8

Dunno whether it would be possible to extend the parser with a unary
variant of it.

> I'd say the same for '&', but can't think of a meaningful '&x = foo'.
>
> > IMHO we have to judge the costs of this change (broken code, confused
> coders
> > :-)) vs. what we gain (more consistency).  Dunno on what side the
balance
> > will come down though.
>
> Imho, a design decision that saves typing a single *, and as a result
makes
> binding variables via the assigment operation inconsistent with binding
> variables via a method call, is one that _should_ be changed for 2.0.

I'm not sure whether I agree.  After all assignment and method call are
not exactly the same although I can see the common issue of variable
binding.  One of the differences is that the assignment has a result:

>> a,b,*c=1,2,3,4
=> [1, 2, 3, 4]
>> x=(a,b,*c=1,2,3,4)
=> [1, 2, 3, 4]
>> x
=> [1, 2, 3, 4]

> What do other Rubyists think of this proposal (assuming there was no
issue
> of backward compatibility) ?

If it wasn't for the backward compatibility issue I think a change would
lead to more consistence.  At least nothing I see at the moment.

Regards

    robert