On Thursday 27 November 2003 12:57 am, Mathieu Bouchard wrote:

Thanks Mathieu. That clears things up very nicely.

Happy Thanksgiving!

-t0

> On Mon, 24 Nov 2003, T. Onoma wrote:
> > Take the def statement for example, why the odd sugar?: def
> > blocky(x,y,&z).  why not def blocky(x,y){z}? But then & isn't exactly
> > just sugar. Is it?
>
> A Ruby message is in four parts:
>
>  * receiver (optional, defaults to self)
>  * selector (symbol of method name)
>  * regular args (including optional "=" args, and *varargs)
>  * block (optional, and not a real value)
>
> The &z assigns to z the result of converting the block part of the active
> message into a Proc object. This conversion happens because blocks are not
> objects (apparently it's a significant speed gain to make it work that
> way?)
>
> > And I still get confused: when do I need the & in my method? And so
> > on.
>
> You need & (or equivalently, Proc.new) when you want to do something with
> the block which is not possible by just using "yield" and "block_given?".
> For example, to pass a block from a method call to another, you need to
> pick up the block using & in the param-list (or Proc.new), and then pass
> it to another method using & in the call.
>
> > I've also wished that Proc/Lambdas had there own unique delimiteres
> > and not shared them with hashes. (Couldn't hashes have shared
> > delimiters with array instead? The => gives them away, after all.)\
>
> Because of the need for a short and obvious way of distinguishing an empty
> array from an empty hash. Apart from that it would have been nice. Another
> idea is that if blocks were always like {|...| ... } with the vertical
> bars, then no confusion is possible. Anyway, { ... } as a block is
> equivalent to {|*| ... } IIRC (or maybe that's yet another thing that
> changed to whatever else in 1.8.)
>
> ________________________________________________________________
> Mathieu Bouchard                       http://artengine.ca/matju