Yes, but not in the helper method. In the code I’ve shown there’s
always a block passed to the helper method. Phlip has a point here.
That’s very easy to solve:
What about the two kinds of performance? Programmer performance and
program performance?
This permits only one (DRY) call to y:
y { yield if block_given? }
So is it performant? Note someone here asserted that yield was faster,
so are these constructions still faster than a brute-force ‘block.call
if block’ ?
When I see ‘if block’ I think of comparing the RVALUE type field to
nil or false. Just a bit mask.
On 8/6/07, Phlip [email protected] wrote:
Ronald F. 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
I actually wanted to say something about this issue but it seems that
my posts got cut, not sent, whatever, even I have difficulties to
understand the fragments.
Please (1) ignore them, (2) excuse me for the noise and (3) blame gmail
;).
Sorry
Robert
Hi –
On Tue, 7 Aug 2007, Phlip wrote:
y { yield if block_given? }
So is it performant? Note someone here asserted that yield was faster,
so are these constructions still faster than a brute-force ‘block.call
if block’ ?
When I see ‘if block’ I think of comparing the RVALUE type field to
nil or false. Just a bit mask.
Here are some benchmarks, for the two conditionals with and without a
block:
david-a-blacks-computer:~/hacking dblack$ cat yi.rb
require ‘benchmark’
include Benchmark
def x(&b)
b.call if b
end
def y
yield if block_given?
end
n = 1000000
bmbm do |b|
b.report(“b”) { n.times { x { } } }
b.report(“y”) { n.times { y { } } }
b.report(“b-no block”) { n.times { x } }
b.report(“y-no block”) { n.times { y } }
end
david-a-blacks-computer:~/hacking dblack$ ruby yi.rb
Rehearsal ----------------------------------------------
b 3.780000 0.010000 3.790000 ( 3.798711)
y 0.700000 0.000000 0.700000 ( 0.695756)
b-no block 0.350000 0.000000 0.350000 ( 0.351118)
y-no block 0.380000 0.000000 0.380000 ( 0.390713)
------------------------------------- total: 5.220000sec
user system total real
b 3.810000 0.000000 3.810000 ( 3.846940)
y 0.700000 0.010000 0.710000 ( 0.760668)
b-no block 0.350000 0.000000 0.350000 ( 0.353762)
y-no block 0.390000 0.000000 0.390000 ( 0.390436)
So if the test is negative, there’s not a huge difference; the
difference mainly comes when there is a block.
David