Re: What about 'splay'?

On 10/12/06, [e-mail] <[e-mail]> wrote:
> Hi --
>
> On Thu, 12 Oct 2006, Dave Burt wrote:
>
> > [e-mail] wrote:
> >> ... The
> >> whole problem, though, is that this method's purpose is to represent
> >> the object as an array, but we can't use to_a or to_ary.  It's hard to
> >> come up with a fully good alternative.
> >
> > Please allow me to disagree. We can and currently do use to_a, and I do
> > not see the benefit of this new method.
> > I think that means you're agreeing :-)

And as you know, I'm in the same camp.

It looks like in the past, to_ary was used.  At least that's what the
Pickaxe implies:

P. 340 Parallel Assignment:
   "1. If the last rvalue is prefixed with an asterisk and implements
to_ary, the rvalue is replaced with the elements of the array, with
each element forming its own rvalue."

P 373 - in the Duck Typing chapter
  "A small number of strict conversion functions are built into the
standard library.

    to_ary -> Array
       Used when the interpreter needs to convert a object into an array for
       parameter passing or multiple assignment.

                 class OneTwo
                      def to_ary
                          [1, 2]
                      end
                 end
                 ot = OneTwo.new
                 a, b = ot
                 puts "a= #{a}, b = #{b}"
                 printf("%d -- %d\n", *ot)

        produces:
                a = 1, b = 2
                1 -- 2

Now it seems that somewhere along the way, the EXPLICIT use * prefix
got changed to use to_a instead of to_ary. Extending the example above

               a, b = *ot
has the same result as
               a, b = ot

Now if we define the class TwoThree

    class TwoThree
           def to_a
                [2, 3]
            end
     end

and now:

     tt = TwoThree.new
     c, d = tt
     c => #<TwoThree:0xb7d6c1d4>
     d => nil

but
     tt = *tt
     c => 2
     d => 3

This is all under 1.8.  Under the current 1.9:

    a, b = ot
    a =>#<TwoThree:0xb7d6c1d4>
    b => nil
    a, b = *ot
    a =>#<TwoThree:0xb7d6c1d4>
    b => nil

    c, d = tt
    c => #<TwoThree:0xb7dc9454>
    d = nil

    c, d = *tt
    c => #<TwoThree:0xb7dc9454>
    d = nil

So, FWIW, the current 1.9 breaks the P 373 example in the Pickaxe.

Now recently, I was going to suggest that instead of to_values,
to_rvalues might be a better name of to_splat if we NEED to have it,
this is because for parallel assignment, or parameter assignment, *
can only really send a message to an rvalue, since on the left hand
side (or in the formal parameter) it really modifies the
interpretation of a variable not an object.

However this morning someone posted _why's trick of using * for a case
branch e.g.

Executives = #w[Fred, Jo, Sally]

case employee
   when *Executives
        # employee is an executive
end

Here, I'm not sure how to classify Executives as either an rvalue or
an lvalue, it's really the receiver of :===  here.

Now that led to another test of 1.8 vs. 1.9

Under 1.8

case 1
 when ot
    puts "got it"
end
=> nil

case 1
   when *ot
      puts "got it"
end
got it
=> nil

So under 1.8 case doesn't implicitly splat case branch values, but it
will use to_ary on an explicit splat.

case 3
   when tt
       puts "got it"
 end
=> nil

case 3
    when *tt
       puts "got it"
    end

Now under the current 1.9 none of these examples work, even _why's case trick.

And that seems to be a shame!

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/