From: Ross Bamford <rossrt@...>
Date: 2006-02-28T07:57:19+09:00
Subject: Re: Dynamic stuff and books

On Tue, 2006-02-28 at 06:33 +0900, Mc Osten wrote:
> On Tue, 28 Feb 2006 02:18:59 +0900, Ross Bamford wrote:
> <http://www.rubyist.net/~slagell/ruby/singletonmethods.html>
> 
> Well, another source of information... here the thing gets more
> interesting. Well an example of a singleton method from the site above is 
> 
> class SingletonTest
>   def size
>     25
>   end
> end
> 
> test2 = SingletonTest.new
> 
> def test2.size
>    10
> end

Answering a later question you had, the above singleton method could be
defined like:

	class << test2
	  def size
	    10
	  end
	end

This is a singleton class definition, which as you noticed is often used
in regular class/module definition contexts to define 'class methods'.
Since self refers to the class being defined, the following:

	class SomeClass
	  # 'self' is SomeClass
	  class << self
	    def size
	      10
	    end
	  end
	end

creates a singleton method on the SomeClass class instance, which is
referred to by the constant 'SomeClass', hence the ability to call it by
'SomeClass.size'.

> The first question that springs into my mind is:
> - May I define a class whose type is not Class? That is to say a class Foo
> such that Foo.class is the object Bang? -- in other terms has Ruby "custom
> metaclasses"?
> 

Well, you can't subclass Class. You can do a bit of this kind of thing
with Module (a superclass of Class), but bear in mind that class names
are just like any other constant in Ruby, so you could do

	class OtherClass
	  def new
	    "Aha!"
	  end
	end

	Foo = OtherClass.new

	Foo.class
	# => OtherClass

	Foo.new
	# => "Aha!"

which is all very confusing, so probably best not to (outside of a few
cases you'll find later I guess).
	
> - The second is: is there some Ruby object that is not an Object (and
> fortunately I'm case sensitive enought not mess with the principle of
> non-contraddiction)? As far as I can see, even Classes are Objects [ and
> that's quite consistent with Python too, since types are objects ]
> 

Yes, everything in Ruby is an object, at least from the point of view of
your Ruby code.

> But... how can it be that *every* Class object... no, I know.
> So if I do some
> 
> class Class
>   def Class.foo(sym)
>     puts "You fooed #{sym}"
>   end
> end
> 
> what am I really doing? This does not work how I expected, that is
> 
> class Foo
>   foo :hi
>   def bar
>     "bar"
>   end
> end
> 
> explodes... so eventually the donkey fell[0]. What's wrong?
> 

Remember that class definitions execute in the context of the class
being defined - an _instance_ of Class (referred to by 'self' there). So
for the code to work, you'd just need to define an instance method on
Class, rather than a singleton method.

For most purposes you'll want to define on Module instead, which allows
your method in both class and module definition contexts.


> ----
> [0] If someone is interested "Casca l'asino" [ the forementioned "The
> donkey falls" ] is roughly equivalent to "All the knots get back to
> the
> comb", but I quite feel more like a donkey than like a knot. It's
> probably
> because I.am_a? Mammal, anyway )

In Ruby Mammal would have to be a module, and I'd say
self.kind_of?(Mammal) :-)

> And somewhere I also saw some &word. What's that? Sorry for the newbie
> question.
> 

As you saw, a lot of stuff in Ruby is done with blocks. You can attach
blocks to method calls, and one of the ways this is done is by declaring
the final argument with a leading ampersand.

Theres a bit about it here:

	http://www.rubycentral.com/book/tut_containers.html

(esp. 'Blocks can be closures' near the bottom)

> > Notice the last four (B and cmethod), where there is no ambiguity
> > (Bmethod takes arguments, and so cannot be a constant, while cmethod
> > lacks the initial lowercase letter that identifies constants). Ruby
> > allows either :: or . to be used here, but generally you should probably
> > stick to using :: for constant references, and . for method calls since
> > it avoids any confusion for the parser and (more importantly) reader.
> 
> Ok. Got it. But for simple functions in a module, shouldn't I use ::?
> I tend not to think to functions like "methods" of an instance of a module
> object (I should definitely have a break), but rather ... well, :: is more
> appropriate in this case, isn't it? :)
> 

Well, in Ruby functions are methods :). I suppose in the unambiguous
cases it's really up to you, but as I say I'd recommend sticking with
the 'standard' (?) usage, simply because it avoids strange errors and
odd behaviour in cases where it's not 100% clear cut what you're
referring to (or worse, could become so after refactoring).

-- 
Ross Bamford - rosco@roscopeco.REMOVE.co.uk