returning(...) ?
Stephen Caudill
scaudill at gmail.com
Tue Sep 4 19:46:58 EDT 2007
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.
> <merb-returning.diff>
> _______________________________________________
> Merb-devel mailing list
> Merb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/merb-devel
More information about the Merb-devel
mailing list