From: furtive.clown@...
Date: 2007-11-13T22:45:02+09:00
Subject: Re: Yielding an object and caring about the result: the cousin of Object#tap

On Nov 13, 5:39 am, Daniel DeLorme <dan...@dan42.com> wrote:
> This kind of suggestion has been made several times in the past and,
> while I agree it looks elegant, I believe the issue is that "as" does
> not really /belong/ to the object on which it is called. It is a utility
> method. If you look at the base methods of Object you'll see that all of
> them have to do with the state of the object itself (except for the ugly
> exception of "display"). Semantically, a utility method has no business
> being part of the public interface of every object.

I think we are generally on the same page, but I would add that to_a,
to_ary, to_hash, to_enum, to_s are utilities as well since they just
output stuff.  If these conversion utilities were not part of the
class then there would be a lot less chaining going on, and
consequently a lot fewer happy programmers.  Ruby got that one right,
even though the fuddy-duddies object to the mutual tying between
classes for the mere sake of convenience.

Therefore it would be consistent to also desire Object#to_arg, another
conversion utility (a.k.a "as") which puts the thing into a block
argument, just as Hash#to_a puts the thing into an array.  (The
analogy is a little forced but still convincing.)  Ruby has already
committed itself to making happy programmers instead of happy language
theoreticians --- why not go this one step further?  Somewhere out
there is a ruby programmer who, though he may not know it now, will be
made happier by it.

A second, separate argument is that the addition of Object#tap should
imply the addition of its complement, Object#as (or Object#to_arg, or
whatever we call it).  A rubyist should notice something inconsistent
in being able to yield an object to a block without affecting the
object, but being unable to yield an object to a block in order to
produce a result.

--FC