From: Mc Osten <riko@...>
Date: 2006-03-01T21:48:36+09:00
Subject: Re: Dynamic stuff and books

On Tue, 28 Feb 2006 22:03:04 +0900, Ross Bamford wrote:

> 'class' here is doing what you expect it to do - defining a class. But
> the class that's being defined is a singleton class belonging to the
> object on the rhs of the <<. Basically, objects in ruby can have two
> classes - the class of which they are an instance, and a singleton class
> that relates to (and supplies methods for) just that object. This syntax
> is for use with the latter.

Ok. Quite got it. It's kind of a new viewpoint to me. In fact it can be
done even in Python, but then it is more natural to see it as "I changed a
method in the dictionary methods" [ basically python objects act much like
dictionaries -- hashes in the ruby world ]

It's probably something I have to meditate upon. Injecting classes I mean. 

> Not quite. You're actually evaluating it in the context of an instance
> of Class, that being the singleton class for 'something'.

So not in the something context, but in a "subclass without name" (the
singleton class). Ok.

So everytime I'm doing something with << and classes I'm working with
subclasses?
	
> Notice how the Class returned relates to just that SomeClass instance.
> (this for the sake of example, if you were to need it you'd probably
> define it elsewhere).

I love it. Quite more clear than the "update dictionary" version.

> No, singleton modules aren't (AFAIK) supported.

irb agrees.

> Mostly that's true, but there is at least one difference to keep in mind
> - multiple class SomeClass ... definitions will 'reopen' the existing
> class and allow new methods to be added:

Yes. That's true. I didn't think about it. It's one of the things I really
love, indeed. But...

Is there anyway to "reopen" a class with the "raw" syntax?

         Something.reopen do
           # code...
         end

I had a look at the ri documentation (and I found out there is a lot of
interesting stuff...) and found anything.
It appears that appending stuff to the "methods" and "public_methods"
arrays is not the way to go...

> And no, no-one is going to get upset about it (well, no-one who does
> Ruby anyway). I consider this kind of metaprogrammability to be one of
> Ruby's sleekest features. Whether your boss, or your customer, or
> whoever else, gets upset about it depends on too many external factors
> to predict :)

This is not an issue... it was just a matter of "style". I come from
Python, there are lots of things that are perfectly legal, but are felt
"unpythonic" and thus better avoided (I'm not speaking of metaprogramming,
but of "bad style").
I was asking if the "good Ruby programmer" was "allowed" to hack in this
sense even in production or if it was considered just an "intellectual
exercise" (as are obfuscated C/Perl contexts).

> The more I thought about this, the more I imagined an enormous class
> hierarchy representing the natural world, so I decided to stop thinking
> about it in the end :)

:))

> 'yield' is usually the way I'd recommend you go, but yes, sometimes you
> need to do something with the block other than call it right away. 

Ok.
 
> (Aside, the 'yield b' in your second example above will actually pass
> the block as an argument to itself).

Uh. Quite interesting... suppose I can do something really nasty with this.
I like it! :)


> Top-level 'functions' are private methods on Object (I was sure it was
> Kernel but it doesn't appear so):

Ok. In fact it told me I was calling a private method, but I did not
understand why. It's meant that way.

> Since they're private, and on Object, you get the expected behaviour
> that you can only call them with no receiver, and from anywhere.

May I ask why?

-- 
USB Priests for only 10$