From: itsme213@... (you CAN teach an old dog ...)
Date: 2003-06-17T09:19:30+09:00
Subject: Re: Reason for implicit block syntax ?

Mauricio Fern�ndez <batsman.geo@yahoo.com> wrote 
> On Mon, Jun 16, 2003 at 06:30:25AM +0900, Mark Wilson wrote:
> >   def ... end
> > does not return a method object because methods are not objects in Ruby 
> > (unless wrapped in a proc object). 

class A; def foo; end; end
p A.instance_method(:foo) ==> #<UnboundMethod: A#foo>

That's the object def ... end should return.

> > I am interested to know what would you want to do with a method object 
> > that was returned after
> >   def ... end
> 
> One application is sugar:
> 
> private def foo
> 	# bla
> end

Or, if I added some methods to the UnboundMethod class (or class
Class), I could start attaching all kinds of interesting meta-data to
these methods.

(def foo ... end) synchronized

Yes, it's only sugar. But then I guess you can call C#'s 'attribute'
facility syntactic sugar as well.

> > The above is a serious question.

The intended use is also serious.

> If he wants class .. end to return the class he can always do
> 
> class Foo 
> 	#bla
> 	self
> end

True. It's less of a dead-end than the 'nil' returned by def...end.