On Tue, 28 Feb 2006 07:57:19 +0900, Ross Bamford wrote:

> Answering a later question you had, the above singleton method could be
> defined like:
> 
> 	class << test2
> 	  def size
> 	    10
> 	  end
> 	end

Quite interesting. I understand its semantic, but not its syntax. That is
to say "class" is a keyword. So this is a "new syntax"?

I think that since I can << array the syntax is not *that* new. Still quite
impressive... well as I said

Every time I do

class << something
 code
end

I'm evaluating "code" in the "something" context? No.. this is not correct.
I understand the example, but I'm not able to make abstraction.

I also suppose i can

module << something
 code
end

I suppose that I should see this as: "add the things I define below to the
object something...
I think I'm not really prepared on the fundamentals. Is there a place where
I can learn (for example what really does the interpreter when it
encounters a "class" definition and such)

So I suppose than 

class Something
 # code
end

is "synactic sugar" for

Somtheing = Class::new do
  # code
end

And if I define something in there, it's like defining a function and then
put it in public_instance_methods (a part that explicitly put it there does
not word, but it works if I public :foo)

> 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'.

Ok. This is clear. So...

When class'ing I'm defining a new Class instance. Then I append methods to
it. I think I got it.

> 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).

Well it looks like a factory object, since then if I Foo.new.class I get
(correctly) String.

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

I knew it was an object. I suppose I can say it is an Object.
 
> 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.

Well... good. Understood. In fact this works as expected

class Class
  def foo(sym)
    puts "You fooed #{sym}"
  end
end

class Foo
  foo :hi
  def bar
    "bar"
  end
end

I've seen that Rails uses a lot this kind of things (for example for
validation) But I suppose they do not add the belongs_to and similar
directly to Class (this is not a question I can go and check the code)
and rather do something like:

class Foo
  def Foo.bar(sym)
    puts "Baaaar: #{sym}"
  end
end

class SubFoo < Foo
   def bar_method
      "bar"
   end
   
   bar :bar_method
end

Then the main question: am I supposed to do this sort of things or is
someone gonna kill me? For example suppose I want to create kind of
synchronized methods (in the Java sense).
Syntactically it is quite beautiful to

synchronize :foo

[ and I think in Monitor.synchronize I would alias :foo, define a
synchronized version of foo that wraps the old :foo ]

If I can do I (theoretically) solved the problem that led me to ask the
first question. But I'm afraid it can't be *that* simple... [ I know Mutex
and works well, it is just to exploit the language features to add new
semantic if needed ].

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

I never thought to modules that way. I'm quite used to Python, where
namespaces are authomatically managed using files. Good.
 
> In Ruby Mammal would have to be a module, and I'd say
> self.kind_of?(Mammal) :-)

Why it would be a Module? In fact I could have functions and methods that
manipulate mammals and I may want to have the forementioned Donkey class to
subclass it.
It's probably a question of Ruby style I've not yet encountered. 

> 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.

Yes. And I do like them a lot. It's one of those things you say "how have I
done _before_?". 

But it does work even without...

def blrun(a)
   puts a
   yield
end

def blrun2(a, &b)
   puts a
   yield b
end


blrun("a") { puts "b" }
blrun2("a") { puts "b" }

I suppose it is useful if you want to "give a name" to the block. Am I
correct?

> Theres a bit about it here:
> 
> 	http://www.rubycentral.com/book/tut_containers.html
> 
> (esp. 'Blocks can be closures' near the bottom)

I go and study.
EDIT: I read that. Amazingly enought I forgot the use of & at all. I
suppose I should go through that book again.

> Well, in Ruby functions are methods :). 

Whose methods are them? I suppose it should be Object or maybe Kernel
(which in fact should be the same since Object includes Kernel, right?)

But I tried to define a method and call it with Object.method and gives
error...


-- 
USB Priests for only 10$