virtual metaclasses explanation

I am getting a bit weighed down at this moment by looking under the
bonnet a bit too  much, but in figure 24.2 in Dave Thomas Pragmatic
Programming,
 classes and objects is is unclear how the metaclass acquires its
additional method as strings.
Dave Rhomas says that the metaclass will inherit all it methods from
its corresponding proper class.

   1. Do all inheritance chains and all objects have a homologue
metaclass at all times, which are behind the scenes?
   2. Do a chain of metaclasses spontaneously appear at the moment
when a class is used as a receiver : so to be used to call a method
inside of a parentclass?
   3. How can a metaclass contain more methods than its corresponding
class has.  Can you give an example of the code in the next addition?
   4. Which is searched first in the inheritance chain.  methods in
the proper parents, or methods in the meta parents?
   5. If a method is found is the search stopped even though another
method with the same name might exist in a parallel chain?

I have made some written notes as I went along which might interest
you.  It is useful to know how the reader is progressing.

def ClassA
def initialize
#some code
end
end

def ClassB
def ClassA.methodX
#code
end
def ClassB.methodY
#code
end
end



both work.
Is this a good idea to define a class method within a different
class?  is this the point of OO or is it bad programming style?

Andy Hunt says

It depends.  In general, that's probably bad style as you're likely
violating the encapsulation of ClassA.

Regards,

/\ndy

\newpage

class ClassA
def initialize
puts "something classA"
end
end

class ClassC
  def initialize
    puts "someting classC"
  end
  def methodY
    puts "beach balls"
  end
end



class ClassB < ClassC
  def methodY
    super
  puts "something ClassB.methodY"
  end
end

test = ClassA.new
stuart = ClassB.new
puts stuart.methodY




stuart = ClassB.methodY

or

stuart = ClassB.new
stuart.methodY

stuart is an object which is initialized of the class method as
ClassB.new which is mostly defined as an ordinary method called
initialize inside of and at the beginnning of the class as ClassB

Sometimes the object as stuart will be referred by as the receiver if
a method within the class by which the object as stuart is defined, is
called after the object name as stuart. i.e stuart.methodY.  Stuart is
reffered by as the receiver so to indicate that the class of the
object as stuart, which in this case is the class as ClassB, contains
a method which the object as stuart may access ; i.e stuart.methodY.

The object as Stuart is related by the class as ClassB.  The object as
stuart is of the class as ClassB.  The word as related means the same
as the word as linked within this context.

Each class may be part of an inheritance chain.

But the class as classB may also be considered an object.  Therefore
the class as classB itself may also be used as a receiver. e.g.

ClassB.methodZ

where the method as Z is defined within the class as ClassC : which is
the parentclass of ClassB.
or
where the method as Z is defined within the class as ClassB' : which
is a virtual class of ClassB.
Because ClassB' is the virtual class of ClassB and Class B is also the
subclass of ClassC, another virtual class as ClassC is established to
be the virtual parentclass of the virual class as ClassB'.  None of
these virtual classes are supposed to be immediately visible.  The
virtual class as ClassB' will contain all the methods of ClassB and
this pattern is repeated through the parallel inheritance chain.







> > QUESTION
> > I'm trying to understand classes and objects. The Pick axe book
> > describes the method as "once"  inside of the class as Date, and how this method is defined
> > by using the object singleton technique as "class << self". Actually
> > the class as Date uses this method at several places. Until I saw the class as Date I thought that the
> > reason by this singleton techinique was to add and replace methods inside of classes at such circumstances when you
> > don't have convenient ways to access by the class definition ; so I conclude that basically,
> > one should use this singleton technique when it's not your class which you need to enhance. But the fact
> > that the class as Date uses this method several times indicates there is another reason to
> > use it.

which is derived from
comp.lang.ruby August 9 2005
Kelly Felkins wrote:
> > I'm trying to understand classes and objects. The Pick axe book
> > points out the "once" method in class Date and how it is defined
> > using the object singleton technique of "class << self". Actually
> > Date uses this in several places. Up until seeing Date I thought the
> > reason for this idiom was to add/replace methods in classes *when you
> > don't have convenient access to the class definition* -- basically,
> > use this when it's not your class you need to enhance. But the fact
> > that Date uses it several times indicates there is another reason to
> > use it.


ANSWER

As you guessed, the reasons are different: typically you use "class
<<something...end" if you have to define several methods or if you
need a
class context for things to work (for example "alias").

These are equivalent:

class Foo
  class <<self
    def m1() "foo" end
  end


  class <<Foo
    def m2() "foo" end
  end


  def self.m3() "foo" end
  def Foo.m4() "foo" end
end


class <<Foo
  def m5() "foo" end
end


def Foo.m6() "foo" end


x = Foo
def x.m7() "foo" end


class <<x
  def m8() "foo" end
end


Now you have methods m1 to m8 as instance methods of Foo.  You can do
Foo.m1(), Foo.m2 etc.

More technically, with class <<something ... end you make definition
for
the so called "singleton class" the class instance responsible for the
single instance at hand (which happens to be a class object in this
case;
but you can repeat the example above with any object instead of Foo).
You
cannot create instances from this class:


irb(main):001:0> class Foo
irb(main):002:1> p new
irb(main):003:1> end
#<Foo:0x10192d58>
=> nil
irb(main):004:0> class <<Foo
irb(main):005:1> p new
irb(main):006:1> end
TypeError: can't create instance of virtual class
        from (irb):5:in `new'
        from (irb):5



-- No virus found in this incoming message. Checked by AVG Free
Edition. Version: 7.5.467 / Virus Database: 269.7.7/816 - Release
Date: 23/05/2007 15:59