[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

yield or call?

Ronald Fischer

8/6/2007 11:02:00 AM

def f(&b)
...
b.call
...
end

def g
...
yield b
...
end

As far I understood the documentation for call and yield, both are
equivalent:

f { ... }
g { ... }

Is there a principal reason when to prefer call over yield (or vice
versa), or are these only syntactic variations of the same feature?

Ronald
--
Ronald Fischer <ronald.fischer@venyon.com>
Phone: +49-89-452133-162
20 Answers

Phlip

8/6/2007 11:28:00 AM

0

Ronald Fischer wrote:

> Is there a principal reason when to prefer call over yield (or vice
> versa), or are these only syntactic variations of the same feature?

I am learning to consider 'yield' as a fossil of an early Ruby that could
not treat the bound block as a variable. I only use 'yield' as a slight
convenience - a few less characters to type - in application-specific code.

When writing API-style code, I always start with &block because it's only a
matter of time before I refactor the code and start passing that &block into
a helper method.

--
Phlip
http://www.oreilly.com/catalog/9780...
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax


Jano Svitok

8/6/2007 11:54:00 AM

0

On 8/6/07, Sylvain Joyeux <sylvain.joyeux@polytechnique.org> wrote:
> On Monday 06 August 2007, Ronald Fischer wrote:
> > def f(&b)
> > ...
> > b.call
> > ...
> > end
> >
> > def g
> > ...
> > yield b
> > ...
> > end
> >
> > As far I understood the documentation for call and yield, both are
> > equivalent:
> >
> > f { ... }
> > g { ... }
> >
> > Is there a principal reason when to prefer call over yield (or vice
> > versa), or are these only syntactic variations of the same feature?
> >
> > Ronald
>
> There is a difference in object allocation. Ruby allocates 1 object for
> each function call, one more in the case of the &b form (it has to
> allocate the Proc).
>
> Then, yield costs only one object while Proc#call costs two. It can make a
> difference in case of large iterations, if you're concerned (like I am)
> about the GC eating your time.
>
> Sylvain
>
>

Jano Svitok

8/6/2007 11:55:00 AM

0

Sorry, this was not intentional...

J.

On 8/6/07, Jano Svitok <jan.svitok@gmail.com> wrote:
>

David A. Black

8/6/2007 12:02:00 PM

0

David A. Black

8/6/2007 12:03:00 PM

0

David A. Black

8/6/2007 12:04:00 PM

0

Ronald Fischer

8/6/2007 12:54:00 PM

0

> > Is there a principal reason when to prefer call over yield (or vice
> > versa), or are these only syntactic variations of the same feature?
>
> I think you mean just yield (not yield b).

Correct!

> yield is a lot faster:

Thank you (and also to all the others) for the clarification.

Ronald

Robert Dober

8/6/2007 1:02:00 PM

0

On 8/6/07, Phlip <phlip2005@gmail.com> wrote:
> Ronald Fischer wrote:
>
> > Is there a principal reason when to prefer call over yield (or vice
> > versa), or are these only syntactic variations of the same feature?
>
> I am learning to consider 'yield' as a fossil of an early Ruby that could
> not treat the bound block as a variable. I only use 'yield' as a slight
> convenience - a few less characters to type - in application-specific code.
Do not do this, yield suffers a lot from a bad reputation it does not
deserve, see also David's benchmarks above.
>
> When writing API-style code, I always start with &block because it's only a
> matter of time before I refactor the code and start passing that &block into
> a helper method.
Why? I do not think that this is necessary.
Just replace the refactoring
old: yield ==> something &blk
>
> --
> Phlip
> http://www.oreilly.com/catalog/9780...
> "Test Driven Ajax (on Rails)"
> assert_xpath, assert_javascript, & assert_ajax
>
>
>


--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein

Robert Dober

8/6/2007 1:57:00 PM

0

On 8/6/07, Phlip <phlip2005@gmail.com> wrote:
> Ronald Fischer wrote:
>
> > Is there a principal reason when to prefer call over yield (or vice
> > versa), or are these only syntactic variations of the same feature?
>
> I am learning to consider 'yield' as a fossil of an early Ruby that could
> not treat the bound block as a variable. I only use 'yield' as a slight
> convenience - a few less characters to type - in application-specific code.
Do not do this, yield suffers a lot from a bad reputation it does not
deserve, see also David's benchmarks above.
>
> When writing API-style code, I always start with &block because it's only a
> matter of time before I refactor the code and start passing that &block into
> a helper method.
Why? I do not think that this is necessary.
Just replace the refactoring
old: yield ==> something &blk + changing the def
with
new: yield ==> something &Proc.new

However I *never* use yield, but for a completely different reason, I
want my def to show if I yield or not.
In case I am unhappy with performance I can still change back.

Cheers
Robert



--
[...] as simple as possible, but no simpler.
-- Attributed to Albert Einstein

Gregory Brown

8/6/2007 2:04:00 PM

0

On 8/6/07, Ronald Fischer <ronald.fischer@venyon.com> wrote:

> Is there a principal reason when to prefer call over yield (or vice
> versa), or are these only syntactic variations of the same feature?

In addition to what others have said (especially David Black), they
throw different errors.

>> def foo
>> yield
>> end
=> nil
>> foo
LocalJumpError: no block given
from (irb):2:in `foo'
from (irb):4
>> def bar(&block)
>> block.call
>> end
=> nil
>> bar
NoMethodError: undefined method `call' for nil:NilClass
from (irb):6:in `bar'
from (irb):8

I also consider yield() to be more idiomatic unless you need to
manipulate or pass along the proc object to another method.