Hi --

On Mon, 3 Jul 2006, gwtmp01 / mac.com wrote:

>
> On Jul 1, 2006, at 8:05 PM, Joel VanderWerf wrote:
>
>> Alexandru Popescu wrote:
>>> Thanks Joel... it looks like my initial understanding was wrong. It is
>>> not block.call the one that triggers block to Proc conversion, but in
>>> fact passing blocks as parameters. Is this the correct understanding?
>> 
>> Right, it happens when the block is passed to a method that expects a 
>> "&block" argument (or if the method explicitly calls Proc.new). If you are 
>> executing "block.call", then "block" is a variable and it, like any 
>> variable, refers to an object.
>
> I like to compare these situations as 'explicit block argument' vs. 'implicit 
> block argument'.  You could also think of it as named vs. anonymous.  In any 
> case, as long as the block remains unnamed/implicit there is no need to 
> package it up into an explicit object (i.e. instance of Proc).  It is the 
> objectification step that burns up the extra cycles.

I see it (subtly) differently.  The block itself isn't an argument to
the method; it's a syntactic construct, more analogous to the argument
list than to a particular argument.  In that capacity, it's always
explicit; that is, it's written out as part of the method call (by
definition).  It's anonymous, but only in the sense that one could say
an argument list is anonymous; there's no ArgumentList class for an
argument list to be a named instance of, and no Block class for blocks
to be named instances of, so anonymity is sort of a red herring.

From that perspective, the objectification is entirely layered on top
of the block; it doesn't change the status of the block per se.


David

-- 
David A. Black (dblack / wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

See what the readers are saying about "Ruby for Rails"!
http://www.rubypowerandlight.com/quotes