specify a mandatory block parameter

S

Shea Martin

I think I know the answer to this already, but...

Is there a what to make a block parameter mandatory?

<code>
def no_block( p_str )
puts "#{p_str}"
end

def block( &p_block )
puts "#{p_block}"
end

no_block #this will cause an exception
block #this doesn't, but is still missing parameter?
</code>

I know, I could just raise my own exception if p_block == nil, just
wondering why the difference? Or am I wrong?

Thanks,

~S
 
D

dblack

Hi --

I think I know the answer to this already, but...

Is there a what to make a block parameter mandatory?

<code>
def no_block( p_str )
puts "#{p_str}"

I believe that in every case, that's exactly equivalent to:

puts p_str

because #{...} interpolates the results of a to_s call, and puts also
calls to_s.
end

def block( &p_block )
puts "#{p_block}"
end

no_block #this will cause an exception
block #this doesn't, but is still missing parameter?
</code>

I know, I could just raise my own exception if p_block == nil, just wondering
why the difference? Or am I wrong?

The block is really in its own category as a semantic (and syntactic)
thing. You can hook into it in the arglist, but it's really a
separate construct -- more on the logical level of the arglist itself,
rather than a particular argument.

You can test for the presence of a block with block_given? or its
synonym, iterator?


David

--
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black
 
S

Shea Martin

Shea said:
I think I know the answer to this already, but...

Is there a what to make a block parameter mandatory?

<code>
def no_block( p_str )
puts "#{p_str}"
end

def block( &p_block )
puts "#{p_block}"
end

no_block #this will cause an exception
block #this doesn't, but is still missing parameter?
</code>

I know, I could just raise my own exception if p_block == nil, just
wondering why the difference? Or am I wrong?

Thanks,

~S

I think you guys missed part of my post:
"I know, I could just raise my own exception if p_block == nil, just
wondering why the difference?"

Although thank you for reinforcing the concept of raising my own exception.

~S
 
S

Shea Martin

Jeffrey said:
So... You want an exception to be thrown, but you don't want to throw
an exception? Please show me what I've missed. Are you saying that
specifying the &p_block parameter should make the block mandatory
automatically?

I am not saying it *should*, but just curious why specifying a block,
does not make it mandatory (automatically)? Specifying a normal
parameter, makes it mandatory (automatically. It just seems odd that
the two are treated differently. Just my $0.02.

~S
 
D

dblack

Hi --

I am not saying it *should*, but just curious why specifying a block, does
not make it mandatory (automatically)? Specifying a normal parameter, makes
it mandatory (automatically. It just seems odd that the two are treated
differently. Just my $0.02.

It's hard for me to answer, because I don't understand why one would
assume, a priori, that they *should* be treated the same :) But in
practice, the code-block facility works out better, I think, the way
it is. The method can easily branch on existence or non-existence of
a block, and it's easy to write methods that can work with or without
a block. I guess I view the &block thing as a special concession to
the possibility that one might want to handle the block as an object
(rather than as a syntactic construct), but not the heart of the
matter.


David

--
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black
 
1

13

Hi,

Blocks are actually objects of class Proc, so if you need to enforce
presence of block parameter then you can do something like this:

irb(main):001:0> p =3D Proc.new { puts 'block' }
=3D> #<Proc:0x02ba5b00@(irb):1>
irb(main):002:0> def method_with_mandatory_block(block)
irb(main):003:1> block.call
irb(main):004:1> end
irb(main):005:0> method_with_mandatory_block p
block
 
E

Eric Schwartz

13 said:
Blocks are actually objects of class Proc

Are you sure? I did a lot of reading up on blocks lately, and from
what I learned, blocks are one of the very few things in Ruby that are
not objects. You can, however, automatically convert them to Proc
objects if you need to; maybe that's what you're noticing?

-=Eric
 
1

13

Hi,

I'm not sure how blocks are treated internally by Ruby (if some expert
can tell us, then it would be great) but when we are using blocks in
our Ruby code then they are objects of class Proc (again, please,
confirm someone if I'm wrong).
 
R

Robert Klemme

13 said:
Hi,

I'm not sure how blocks are treated internally by Ruby (if some expert
can tell us, then it would be great) but when we are using blocks in
our Ruby code then they are objects of class Proc (again, please,
confirm someone if I'm wrong).

Actually Eric is right. They are only objects if you request them to be.

def foo
# no object
yield 1
end

def bar(&b)
# Proc instance
b[2]
end

Kind regards

robert
 
D

dblack

Hi --

Hi,

I'm not sure how blocks are treated internally by Ruby (if some expert
can tell us, then it would be great) but when we are using blocks in
our Ruby code then they are objects of class Proc (again, please,
confirm someone if I'm wrong).

Consider this:

a.each {|b| puts b.capitalize }

That's a method call with a block. But the block is just a syntactic
construct; it's not a Proc object.

You can convert back and forth between blocks and Procs, in various
ways, but there is such a thing as a block that is just a block.


David



--
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top