Asp Forum - arg, metaclass bug found?

Lionel Thiry

4/30/2005 2:28:00 AM

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

--
Lionel Thiry

Personal website: http://users.skynet....

11 Answers

nobu.nokada

4/30/2005 3:21:00 AM

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.

--
Nobu Nakada

Lionel Thiry

4/30/2005 12:10:00 PM

nobu.nokada@softhome.net 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! :)

--
Lionel Thiry

Personal website: http://users.skynet....

Robert Klemme

4/30/2005 10:49:00 PM

<nobu.nokada@softhome.net> schrieb im Newsbeitrag
news:200504300320.j3U3KaYY017937@sharui.nakada.niregi.kanuma.tochigi.jp...
> 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

5/1/2005 9:35:00 AM

Robert Klemme wrote:
>
> <nobu.nokada@softhome.net> schrieb im Newsbeitrag
> news:200504300320.j3U3KaYY017937@sharui.nakada.niregi.kanuma.tochigi.jp...
>
>> 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>

--
Mark Sparshatt

Robert Klemme

5/1/2005 10:00:00 AM

"mark sparshatt" <msparshatt@yahoo.co.uk> schrieb im Newsbeitrag
news:42749FBC.5000504@yahoo.co.uk...
> Robert Klemme wrote:
>>
>> <nobu.nokada@softhome.net> schrieb im Newsbeitrag
>> news:200504300320.j3U3KaYY017937@sharui.nakada.niregi.kanuma.tochigi.jp...
>>
>>> 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

5/1/2005 10:25:00 AM

>>>>> "R" == Robert Klemme <bob.news@gmx.net> writes:

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.send(:initialize, *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 R.

5/1/2005 1:02:00 PM

Robert Klemme schrieb:

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

5/1/2005 1:09:00 PM

Robert Klemme

5/1/2005 7:44:00 PM

"ts" <decoux@moulon.inra.fr> schrieb im Newsbeitrag
news:200505011024.j41AOgMw007111@moulon.inra.fr...
>>>>>> "R" == Robert Klemme <bob.news@gmx.net> writes:
>
> 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.send(:initialize, *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

5/1/2005 7:56:00 PM

Robert Klemme wrote:
>
> 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

--
Mark Sparshatt

comp.lang.ruby

arg, metaclass bug found?

Lionel Thiry

nobu.nokada

Lionel Thiry

Robert Klemme

mark sparshatt

Robert Klemme

ts

Christoph R.

Christoph R.

Robert Klemme

mark sparshatt

x Login to ForumsZone