returning(...) ?

[Josh Susser]

returning() as the k-combinator is fairly cool, but I like the more  
object-oriented Object#tap better, and it's going to be standard in  
Ruby 1.9 too.  See http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9#l25

I've read different things about the overhead of returning()/tap,  
ranging from mildly more overhead to significant, but haven't done  
any measurements myself.  But either way, we can make it kick butt in  
Rubinius, so you should be able to use it guilt-free someday.

--josh

On Sep 4, 2007, at 6:37 PM, Zack Chandler wrote:

> I like having the options of using the syntax sugar (when appropriate)
> of returning and with_options.  I totally agree that the framework can
> do without due these idioms due to performance requirements but as an
> app developer I'd like the option where cleanliness/beauty is valued
> more than a small speedup.
>
> Zack
>
> On 9/4/07, Stephen Caudill <scaudill at gmail.com> wrote:
>> Fixed this in r511.
>>
>> I still think there's a time and a place for that pattern.  It's not
>> magical and it follows a clear precedent in good OO design.  It is
>> decidedly *not* as performant as it's sometimes longer handed
>> counterpart, but Ruby is a language in which the value of being
>> succinct is frequently more important than being very fast.  I'd
>> rather not sacrifice a bit of beauty in my code for a few
>> milliseconds parsing difference, since most of the overhead occurs in
>> method dispatch.
>>
>> just my 2¢
>>
>> --
>>
>> Stephen Caudill (voxdolo)
>>
>> On Sep 4, 2007, at 4:46 PM, Brian Candler wrote:
>>
>>> The following construct is an ActiveSupport-ism:
>>>
>>>   returning(Foo.new) do |foo|
>>>     ...
>>>   end
>>>
>>> I don't especially like it, since it's both more verbose and less
>>> efficient
>>> than the direct alternative:
>>>
>>>   foo = Foo.new
>>>   ...
>>>   foo
>>>
>>> It doesn't occur many times in Merb, so does anyone agree with me
>>> that it
>>> should be removed?
>>>
>>> I tried doing this (patch attached) and I find the code more  
>>> readable
>>> without. For example, in lib/merb/mixins/responder.rb
>>>
>>> Before:
>>>
>>>         def <=>(entry)
>>>           returning((entry.quality <=> quality).to_s) do |c|
>>>             c.replace((index <=> entry.index).to_s) if c == '0'
>>>           end.to_i
>>>         end
>>>
>>> After:
>>>
>>>         def <=>(entry)
>>>           c = (entry.quality <=> quality).to_s
>>>           c.replace((index <=> entry.index).to_s) if c == '0'
>>>           c.to_i
>>>         end
>>>
>>> This second form also more clearly begs the question, why is the
>>> result from
>>> <=> being converted to string and then back to integer? I don't
>>> know the
>>> answer to that :-)
>>>
>>> I believe the attached patch is OK - it doesn't break any specs. It
>>> doesn't
>>> remove the definition of Object#returning itself, or its spec.
>>>
>>> Regards,
>>>
>>> Brian.

--
Josh Susser
http://blog.hasmanythrough.com