Forum: Ruby specify a mandatory block parameter

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F330a44fdf083a7a30488efc47759f3f?d=identicon&s=25 Shea Martin (Guest)
on 2006-03-16 21:10
(Received via mailing list)
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
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-16 21:29
(Received via mailing list)
Hi --

On Fri, 17 Mar 2006, Shea Martin wrote:

> 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.

> 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 (dblack@wobblini.net)
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
149379873fe2cb70e550c6bff8fedd0c?d=identicon&s=25 Jeffrey Schwab (Guest)
on 2006-03-16 21:35
(Received via mailing list)
Shea Martin wrote:
>     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?

Do you mean something like this?

def f
     throw "D'oh!  No block." unless block_given?
     puts "OK, got a block."
end

begin
     f { }
     f
rescue
     puts $!
end
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-16 21:41
(Received via mailing list)
Hi --

On Fri, 17 Mar 2006, Jeffrey Schwab wrote:

>> def block( &p_block )
> Do you mean something like this?
>
> def f
>    throw "D'oh!  No block." unless block_given?

I think you mean "raise" :-)


David

--
David A. Black (dblack@wobblini.net)
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
149379873fe2cb70e550c6bff8fedd0c?d=identicon&s=25 Jeffrey Schwab (Guest)
on 2006-03-16 23:04
(Received via mailing list)
dblack@wobblini.net wrote:

>> def f
>>    throw "D'oh!  No block." unless block_given?
>
> I think you mean "raise" :-)

I reiterate:  D'oh!
F330a44fdf083a7a30488efc47759f3f?d=identicon&s=25 Shea Martin (Guest)
on 2006-03-17 14:25
(Received via mailing list)
Shea Martin wrote:
>     puts "#{p_block}"
>
> ~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
149379873fe2cb70e550c6bff8fedd0c?d=identicon&s=25 Jeffrey Schwab (Guest)
on 2006-03-17 15:09
(Received via mailing list)
Shea Martin wrote:
>> def block( &p_block )
>> 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?"

That's not the same thing.  If you use block_given? as David Black and I
suggested, there is no p_block to check for nil.

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

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?  Hmmm...  I don't know of a way to enforce the presence
of a mandatory block without raising any exceptions.
F330a44fdf083a7a30488efc47759f3f?d=identicon&s=25 Shea Martin (Guest)
on 2006-03-20 16:24
(Received via mailing list)
Jeffrey Schwab wrote:

> 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
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-20 16:42
(Received via mailing list)
Hi --

On Tue, 21 Mar 2006, Shea Martin wrote:

> 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 (dblack@wobblini.net)
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
Be13d49ea40add75e564bef96b323caf?d=identicon&s=25 13 (Guest)
on 2006-03-21 20:03
(Received via mailing list)
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 = Proc.new { puts 'block' }
=> #<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

--
Martins
4df2f657ab76cbe68ad71628b24d2c91?d=identicon&s=25 Eric Schwartz (Guest)
on 2006-03-23 00:43
(Received via mailing list)
13 <one.three@gmail.com> writes:
> 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
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-23 00:56
(Received via mailing list)
Hi --

On Thu, 23 Mar 2006, Eric Schwartz wrote:

> 13 <one.three@gmail.com> writes:
>> 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?

That's correct; the block is a syntactic construct (like argument
list, which also isn't an object).  I think there may have once been a
Block class in CVS once for a day or two, as part of the evolution of
the whole block/lambda/Proc sphere, but if so it was just an
experiment and not pursued.


David

--
David A. Black (dblack@wobblini.net)
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
Be13d49ea40add75e564bef96b323caf?d=identicon&s=25 13 (Guest)
on 2006-03-23 16:26
(Received via mailing list)
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).

--
Martins
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-23 16:48
(Received via mailing list)
Hi --

On Fri, 24 Mar 2006, 13 wrote:

> 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



>> not objects.  You can, however, automatically convert them to Proc
>> objects if you need to; maybe that's what you're noticing?
>>
>> -=Eric
>>
>>
>
>

--
David A. Black (dblack@wobblini.net)
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
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 Robert Klemme (Guest)
on 2006-03-23 16:48
(Received via mailing list)
13 wrote:
>
> On 3/23/06, Eric Schwartz <emschwar@fc.hp.com> wrote:
>> 13 <one.three@gmail.com> writes:
>>> 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

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
This topic is locked and can not be replied to.