returning(...) ?

[Zack Chandler]

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.
> > <merb-returning.diff>
> > _______________________________________________
> > Merb-devel mailing list
> > Merb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/merb-devel
>
> _______________________________________________
> Merb-devel mailing list
> Merb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/merb-devel
>