Re: want_object? - possible?

On 3/24/05, David A. Black <[e-mail]> wrote:
> Hi --
> 
> On Fri, 25 Mar 2005, Daniel Berger wrote:
> 
> > Keep in mind that some of the contexts mentioned there
> > do not apply to Ruby, e.g. lvalue subs.  In fact, most
> > may not.  But, if there were some way for a method to
> > detect whether it's part of a chain in advance, that
> > might be useful.
> 
> I don't think there is a way, logically, within the basic
> message-receiver-response model.  The idea of an object knowing what
> is going to happen after it finishes responding to the message seems,
> to me, to be part of a pretty deeply different design.  At that point,
> also, you're not really chaining method calls; you're using
> method-chaining syntax to execute something that's really not linear
> from left to right.  At that point, the a.b.c syntax starts to obscure
> what's really happening, rather than revealing it, I think.

There are occasions where a nice uses_return_value? would help:

module Enumerable
  def zip(*others)
    if block_given?
      if uses_return_value?
        # build a new array using the block, return it
      else
        # yield each set of elements, don't build array.
      end
    [...]

and using it with method chaining:

(1..26).zip('a'..'z'){|n,c| n.to_s + c}.map{|v| #do stuff here}

Looks good to me!

The main argument (in a recent ruby-talk discussion) against having
zip+block return an array was based on performance issues. If we had a
way to determine whether the caller needs a return value, that could
be avoided. I would see this method mainly as an optimization tool, if
it was added.

Note: I'm not advocating the change, I'm just pointing out some useful
possibilities. I'm not going to pretend to know the best design for
Ruby; I'll happily leave that to Matz, who's done awfully well so far
:)

cheers,
Mark