Hi --

On Sun, 23 Nov 2008, Radosaw Buat wrote:

> On Sun, Nov 23, 2008 at 10:00 AM, David A. Black <dblack / rubypal.com> wrote:
>> Hi --
>>
>> In this code:
>>
>>>> def m(a,b="b",c="c",d); p [a,b,c,d]; end
>>
>> => nil
>>>>
>>>> m(1,2,3)
>>
>> [1, 2, "c", 3]
>> => [1, 2, "c", 3]
>>
>> I would expect [1, 3, "c", 2], because I would expect d (a required
>> argument) to be handled before b (an optional argument).
>
> As far as I understand it works OK.
>>
>> I know it's almost unthinkable that one would use this method
>> signature, but I'd still like to understand the reasoning fully. I
>> thought the idea was: handle the required arguments first, but it
>> seems to be: move from left to right, looking ahead at every point to
>> see whether there are enough arguments left and, at that point, give
>> the right-hand required arguments priority. Is that right?
>
> [explanation snipped]

You know, I should have just gone back and read Chapter 2 of the new
version of my book :-) Here's what I say for a (a,b,*c,d) example:

   The parameters a and b get the first two arguments, 1 and 2. Because
   the parameter at the end of the list, d, represents a required
   argument, it grabs the first available value from the right-hand end
   of the argument list?namely, 5. Whatever?s left in the middle (3,4)
   gets sponged up by c.

It's that "from the right-hand side of the argument list" that for
some reason I wasn't taking into account when I started this thread,
as your explanation made clear.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
   Intro to Ruby on Rails  January 12-15   Fort Lauderdale, FL
   Advancing with Rails    January 19-22   Fort Lauderdale, FL *
   * Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!