arg, metaclass bug found?

[Lionel Thiry]

Hello!

A lot explore the deeps of the metaclass/idioclass stuff, so do I. I've done
some simple tests and found what looks like a bug for me, or at last, I did not
expected that result at all. I may be wrong, but I can't see where.

----8<----
class Object
def meta #meta is shorter than anything else
class << self; self; end
end
end

class Test1
class << self
def test
"from Test1.meta"
end
end
end

class Test2 < Test1
end

Test2 < Test1 # => true

# the bug is here
Test2.meta < Test1.meta # => nil
# it should have benn true instead of nil

# this test prove that Test2 has inherited the singleton method of Test1
Test2.test == "from Test1.meta" # => true
----8<----

 

[nobu.nokada]

Hi,

At Sat, 30 Apr 2005 11:29:27 +0900,
Lionel Thiry wrote in [ruby-talk:140557]:

Test2 < Test1 # => true

# the bug is here
Test2.meta < Test1.meta # => nil
# it should have benn true instead of nil

true is returned in 1.9.

 

[Lionel Thiry]

(e-mail address removed) a écrit :

Hi,

At Sat, 30 Apr 2005 11:29:27 +0900,
Lionel Thiry wrote in [ruby-talk:140557]:

Test2 < Test1 # => true

# the bug is here
Test2.meta < Test1.meta # => nil
# it should have benn true instead of nil

true is returned in 1.9.

Ok, I'm reassured, thanks!

 

[Robert Klemme]

Hi,

At Sat, 30 Apr 2005 11:29:27 +0900,
Lionel Thiry wrote in [ruby-talk:140557]:

Test2 < Test1 # => true

# the bug is here
Test2.meta < Test1.meta # => nil
# it should have benn true instead of nil

true is returned in 1.9.

Hm, why is that? What do the singleton classes of Test2 and Test1 have in
common? This surprises me...

Kind regards

robert

 

[mark sparshatt]

Hi,

At Sat, 30 Apr 2005 11:29:27 +0900,
Lionel Thiry wrote in [ruby-talk:140557]:

Test2 < Test1 # => true

# the bug is here
Test2.meta < Test1.meta # => nil
# it should have benn true instead of nil

true is returned in 1.9.

Hm, why is that? What do the singleton classes of Test2 and Test1 have
in common? This surprises me...

According to the Pickaxe if Test2 is a subclass of Test1 then Test2.meta
should be a subclass of Test1.meta

Entering

Test2.meta.superclass #=> #<Class:Test1>

 

[Robert Klemme]

Hi,

At Sat, 30 Apr 2005 11:29:27 +0900,
Lionel Thiry wrote in [ruby-talk:140557]:

Test2 < Test1 # => true

# the bug is here
Test2.meta < Test1.meta # => nil
# it should have benn true instead of nil


true is returned in 1.9.

Hm, why is that? What do the singleton classes of Test2 and Test1 have
in common? This surprises me...

According to the Pickaxe if Test2 is a subclass of Test1 then Test2.meta
should be a subclass of Test1.meta

Entering

Test2.meta.superclass #=> #<Class:Test1>

Well, yes, that's what I concluded. But why is that so? What's the
reasoning behind this? After all, both singleton classes are just there for
a single object although that happens to be a class instance. This change
might even break some code, I'm not sure.

Kind regards

robert

 

[ts]

R> Well, yes, that's what I concluded. But why is that so? What's the
R> reasoning behind this? After all, both singleton classes are just there for
R> a single object although that happens to be a class instance. This change
R> might even break some code, I'm not sure.

Well, I've tried one day to give a *STUPID* example

Imagine that you have


class Class
def new(*args, &block)
obj = allocate
obj.sendinitialize, *args, &block)
obj
end
end

class Array
def self.allocate
# do some magic here to create the type array
end
end

Now if you write

class A < Array
end

A.new

You want with `A.new' re-use the method ::allocate which is defined in the
singleton class (Array). This mean that (A) must inherit from (Array)


Guy Decoux

 

[Christoph]

Well, yes, that's what I concluded. But why is that so? What's the
reasoning behind this? After all, both singleton classes are just
there for a single object although that happens to be a class
instance. This change might even break some code, I'm not sure.

A main difference between, actually the main difference, between
including modules and inheriting from a class (the philosophical issue of MI
aside) is fact that class methods are "inherited" but module methods
are not
"included".
As for code breakage - think marshaling, generalized constructors (e.g.
the Hash or Set "[]" class operators), class instance variable
accessors +
tons of other stuff ...

/Christoph

 

[Christoph]

Well, yes, that's what I concluded. But why is that so? What's the
reasoning behind this? After all, both singleton classes are just
there for a single object although that happens to be a class
instance. This change might even break some code, I'm not sure.

A main difference between, actually the main difference, between
including modules and inheriting from a class (the philosophical issue of MI
aside) is fact that class methods are "inherited" but module methods
are not
"included".
As for code breakage - think marshaling, generalized constructors (e.g.
the Hash or Set "[]" class operators), class instance variable
accessors +
tons of other stuff ...

/Christoph

 

[Robert Klemme]

R> Well, yes, that's what I concluded. But why is that so? What's the
R> reasoning behind this? After all, both singleton classes are just
there for
R> a single object although that happens to be a class instance. This
change
R> might even break some code, I'm not sure.

Well, I've tried one day to give a *STUPID* example

Imagine that you have


class Class
def new(*args, &block)
obj = allocate
obj.sendinitialize, *args, &block)
obj
end
end

class Array
def self.allocate
# do some magic here to create the type array
end
end

Now if you write

class A < Array
end

A.new

You want with `A.new' re-use the method ::allocate which is defined in the
singleton class (Array). This mean that (A) must inherit from (Array)

Sounds reasonable. Thanks for that example!

Still, this seems quite some change to me, doesn't it? I guess this
inheritance does only work for class instance singleton classes - at least
that seems the most reasonable (only?) way to do it to me. That would also
reduce the likelyhood of code breakage. .... It seems, incombatibility
isn't that big issue as I thought initially. That's nice!

Kind regards

robert

 

[mark sparshatt]

Sounds reasonable. Thanks for that example!

Still, this seems quite some change to me, doesn't it? I guess this
inheritance does only work for class instance singleton classes - at
least that seems the most reasonable (only?) way to do it to me. That
would also reduce the likelyhood of code breakage. .... It seems,
incombatibility isn't that big issue as I thought initially. That's nice!

I don't think that that much has changed. In the case of

require "metaid"

class A
end

class B < A
end

B.metaclass has always been a subclass of A.metaclass

The only change in 1.9 is the fact that B.metaclass < A.metaclass now
returns true

 

[Robert Klemme]

I don't think that that much has changed. In the case of

require "metaid"

class A
end

class B < A
end

B.metaclass has always been a subclass of A.metaclass

Oh, I wasn't aware of that. *duh* Learn something new every day. Thanks
for educating me!

The only change in 1.9 is the fact that B.metaclass < A.metaclass now
returns true

Ok, I see. Then it's indee minor.

Kind regards

robert