From: Mc Osten Date: 2006-02-28T06:33:37+09:00 Subject: Re: Dynamic stuff and books On Tue, 28 Feb 2006 02:18:59 +0900, Ross Bamford wrote: > I'll skip to the bits I might be able to help with :) It's the reason why i put the index. I supposed many people would have answered the more "amusing" ruby questions, but not the book ones :) I perfectly know how boring are those "noob questions", unfortunately it's almost irresistible to ask them. :)) > I've been puzzled by this before, but I think a.foo calls are dispatched > directly by Ruby, although send and __send__ will be used explicitly in > other code, including the standard libraries. Even if this were not the > case I guess you'd be unlikely to see _all_ calls go through __send__ > (I'm thinking of methods implemented in C). Ok. So I assume that wasn't the correct way to do it and stop trying to fool ruby with __send__. > You can do stuff like this, though, if you want to trap calls to a given > method, whether it's implemented in Ruby or C: > > class A > def foo > "foo" > end > end > > # ... later ... > > class A > alias :__old_foo :foo > def foo > # do something > __old_foo > end > end > > Maybe what you need, or maybe not... I suppose it does it. I totally missed that function. It gives me a lot of flexibility, I think I can use it to solve my troubles. > attr and friends are singleton methods (a bit like class methods) on > class Module, and are used in the scope of class or module definitions. Are they the rb_attr functions defined in eval.c? I think so. Good. And I did not know they were called "singleton methods". I probably should read the Practical Programmer Guide with more attention (in fact I was to amazed to reason properly). I found some more information here: 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 [ and I'm not really sure I do like this... anyway ] Then I read here (where "here" is ) that if I declare a singleton method for a class object I get a "class method". That is to say class Foo def Foo.bar "foobar" end end And so I think I found a really important use for singleton methods, so I think I should love them, since I love class methods. :) And now... | Methods which are defined in class Class can be used as class methods for every class(!) That is to say I could imagine that if Ruby were written in Ruby I would have class Class def Class.attr(symbol, v) # ... end end Right? [ no, I'm backtracking and I know I'm wrong, but I don't know why ] And now "the donkey falls" (rough translation of an italian motto -- of course the donkey mentioned above it is me). Class is Object class. Right? ( I think so, and irb tends to confirm my supposition -- and I should subscribe this ng on my Mac since I'm starting to hate fxri *give* *me* *readline* ). 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"? - 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 ] 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? ---- [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 ) > They're an example of metaprogramming - when called, they create new > instance methods on the class being defined, almost as if you'd 'def'ed > them yourself (although they're faster since they, like attr(.*) itself, > is implemented in C). Yes. I do like this. In fact it is what I was looking for. Unfortunately as you may have noticed I tend to write before I think, thus producing posts that are comparable with book chapters. Not because they're good, but because they are long. Should learn to write haiku posts, definitely. > You might find some enlightenment on the technique in a recent Ruby > Quiz: > > http://www.rubyquiz.com/quiz67.html This is *wonderful*. And I feel noob. There are a lot of things I do not understand. So... for example Class::new is a bit strange to me. I suppose I learned a new thing. For example this works as expected C = Class::new do def foo "foo" end end puts C.class c = C.new puts c.foo puts c.class So if I pass Class::new a block, the block is executed as if it were the "body" of a class statement. Right? May I generalize this? There are other useful Class::methods to learn? Class::new looks like the object oriented version of lambda. Is it true? But then... class << self def is mysterious to me. And somewhere I also saw some &word. What's that? Sorry for the newbie question. > 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? :) -- USB Priests for only 10$