[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

infinite number of singleton_classes

Lionel Thiry

5/15/2005 1:02:00 AM

Hello!

----8<----
a = Object.new

b = class << a
class << self
class << self
class << self
# "class << self".times(n)
self
# "end".times(n)
end
end
end
end
# => #<Class:#<Class:#<Class:#<Class:#<Object:0x2aa8348>>>>>
----8<----

How many levels can we reach? It seems there is no limit.

I suppose those singleton_class exists only when needed? Otherwise, I really
wonder where does ruby hide all those singleton_classes...

But, sincerely, is it needed to have the singleton_class of a singleton_class?
Isn't it a non-sense? Shouldn't this raise an error?

---8<---
a = Object.new

begin
b = class << a
class << self
self
end
end
rescue NewError
puts "Sincerely, you don't need the singleton_class of the singleton_class!"
end
---8<---

What do you think of it? Isn't it worth an RCR?

--
Lionel Thiry

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

Christoph R.

5/15/2005 2:15:00 AM

0

Lionel Thiry schrieb:

>How many levels can we reach? It seems there is no limit.
>
>I suppose those singleton_class exists only when needed? Otherwise, I really
>wonder where does ruby hide all those singleton_classes...
>
>But, sincerely, is it needed to have the singleton_class of a singleton_class?
>Isn't it a non-sense? Shouldn't this raise an error?
>
>
I agree, it should not be possible to these classes ...

>---8<---
>a = Object.new
>
>begin
> b = class << a
> class << self
> self
> end
> end
>rescue NewError
> puts "Sincerely, you don't need the singleton_class of the singleton_class!"
>end
>---8<---
>
>What do you think of it? Isn't it worth an RCR?
>
>
Yes lets get rid of them, they are utterly useless and
a source of distraction (well at least they have been
in past for me:-)

/Christoph

Ara.T.Howard

5/15/2005 3:39:00 PM

0

dblack

5/15/2005 4:11:00 PM

0

Lionel Thiry

5/15/2005 9:49:00 PM

0

Ara.T.Howard@noaa.gov a écrit :
> On Sun, 15 May 2005, Lionel Thiry wrote:
>
>> Hello!
>>
>> ----8<----
>> a = Object.new
>>
>> b = class << a
>> class << self
>> class << self
>> class << self
>> # "class << self".times(n)
>> self
>> # "end".times(n)
>> end
>> end
>> end
>> end
>> # => #<Class:#<Class:#<Class:#<Class:#<Object:0x2aa8348>>>>>
>> ----8<----
>>
>> How many levels can we reach? It seems there is no limit.
>>
>> I suppose those singleton_class exists only when needed? Otherwise, I
>> really
>> wonder where does ruby hide all those singleton_classes...
>>
>> But, sincerely, is it needed to have the singleton_class of a
>> singleton_class?
>> Isn't it a non-sense? Shouldn't this raise an error?
>>
>> ---8<---
>> a = Object.new
>>
>> begin
>> b = class << a
>> class << self
>> self
>> end
>> end
>> rescue NewError
>> puts "Sincerely, you don't need the singleton_class of the
>> singleton_class!"
>> end
>> ---8<---
>>
>> What do you think of it? Isn't it worth an RCR?
>
>
>
> i've found them useful in the following situation:
>
> harp:~ > cat a.rb
> class C
> class << self
> class << self
> def class_method_generator name
> module_eval <<-code
> def #{ name }; @#{ name }; end
> alias #{ name }? #{ name }
> def #{ name }= value; @#{ name } = value; end
> code
> end
> end
> %w( a b c ).each{|meth| class_method_generator meth}
> end
> end
>
> class B < C
> end
>
> C.a = 42
> p C.a
>
> B.a = 'forty-two'
> p B.a
>
> C.class_method_generator :x
>
>
> harp:~ > ruby a.rb
> 42
> "forty-two"
> a.rb:25: undefined method `class_method_generator' for C:Class
> (NoMethodError)
>
> granted, you could do this with a private class method of C - but this
> is what
> singleton methods are for : defining a method on 'this' instance right here
> and right now that only that instance should be able to do. in this
> case the
> instance happens to be a singleton of a singleton.
>
> in any case i don't think one can say when/if that construct would be
> useful a
> priori and think that having that notion enforced by ruby itself ( __i__
> know
> when need a singleton class and __you__ don't ) is the kind of exception
> that
> reminds of of a 'p' language. ruby programmers are continually pushing the
> boundries of oo coding precisely because matz has given them the tools
> to do
> so and it would be a shame to take a tool away just because someone hasn't
> figured out something indespesible to do with that particular tool __yet__.
>
> kind regards.
>
> -a

I just ask for opinions, you know... :(

What did make you so angry? The fact that I've thought it could be worth an RCR?

--
Lionel Thiry

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

Hal E. Fulton

5/15/2005 9:57:00 PM

0

Lionel Thiry wrote:
>
> I just ask for opinions, you know... :(
>
> What did make you so angry? The fact that I've thought it could be worth an RCR?
>

You have misunderstood somewhere. Ara was not angry.

His "__i__" and "__you__" were quotes -- the Ruby interpreter
talking to the programmer.


Hal

Christoph R.

5/15/2005 10:45:00 PM

0

David A. Black schrieb:

>
> Also, I don't see any harm or danger here. I suppose one could
> accidentally write a loop that kept creating singleton classes, but
> one could also write a loop that kept creating *non*-singleton classes
> -- or arrays, or hashes, or MyClass objects, and so on.

At least you can print any self referential (looping) object involving the
standard container classes, Hash, Arrays. Structs and Sets- however

---
class O
end

CrashChild = class << O; self end.dup

Crash = class << CrashChild
superclass
end

Crash.inspect
---

results in a system stack overflow (for the "stock 1.8.2 windows
installer" ruby). This probably has to do with the fact that the
superclass of a normal "singleton singleton class" of a class, is
necessarily equal to

Klass = class << Class; self end # singleton class of class Class, e.g.
---
class O
end

nocrash = class << (class << O; self end)
superclass
end

Klass = class << Class; self end

p (nocrash == Klass) # true
---

The core problem is (I assume because of efficiency reasons), that Matz
took "a little short cut" of not creating the natural chain of "higher
order"
singleton classes, and cheated by declaring the superclass of any
"higher order" singleton class to be Klass.

Instead of going to the trouble of implementing an ad hoc "higher order
singleton class scheme" (b.t.w. - Ruby had a completely different higher
order singleton class scheme in past) it might have been wiser,
well at least less work, of preventing the creation of "higher order"
singleton classes in the first place.

/Christoph

dblack

5/15/2005 11:15:00 PM

0

Lionel Thiry

5/15/2005 11:18:00 PM

0

Hal Fulton a écrit :
> Lionel Thiry wrote:
>
>>
>> I just ask for opinions, you know... :(
>>
>> What did make you so angry? The fact that I've thought it could be
>> worth an RCR?
>>
>
> You have misunderstood somewhere. Ara was not angry.
>
> His "__i__" and "__you__" were quotes -- the Ruby interpreter
> talking to the programmer.
>

In that quote, Ara *was* angry, not with me, but about the 'p' language.

But here:
----8<---
it would be a shame to take a tool away just because someone hasn't figured out
something indespesible to do with that particular tool __yet__
---8<---

Have I misunderstood something once again?

--
Lionel Thiry

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

Lionel Thiry

5/15/2005 11:19:00 PM

0

David A. Black a écrit :
> Hi --
>
> On Sun, 15 May 2005, Lionel Thiry wrote:
>
>> Hello!
>>
>> ----8<----
>> a = Object.new
>>
>> b = class << a
>> class << self
>> class << self
>> class << self
>> # "class << self".times(n)
>> self
>> # "end".times(n)
>> end
>> end
>> end
>> end
>> # => #<Class:#<Class:#<Class:#<Class:#<Object:0x2aa8348>>>>>
>> ----8<----
>>
>> How many levels can we reach? It seems there is no limit.
>>
>> I suppose those singleton_class exists only when needed? Otherwise, I
>> really
>> wonder where does ruby hide all those singleton_classes...
>>
>> But, sincerely, is it needed to have the singleton_class of a
>> singleton_class?
>> Isn't it a non-sense? Shouldn't this raise an error?
>
>
> [...]
>
>> What do you think of it? Isn't it worth an RCR?
>
>
> No; it's just a consequence of the underlying design principles. Yes,
> there are a few objects that can't have a singleton class (Fixnums and
> Symbols are the ones I can think of). But Class objects can, and
> singleton classes are Class objects. So you'd be asking for
> special-case treatment for a subset of classes.
>
> It would be a bit like saying: Surely no one will ever use a
> singleton class as a hash key, so let's remove the #hash method from
> it. There's just no reason to constrain the language and its usage
> that way.
>
> Also, I don't see any harm or danger here. I suppose one could
> accidentally write a loop that kept creating singleton classes, but
> one could also write a loop that kept creating *non*-singleton classes
> -- or arrays, or hashes, or MyClass objects, and so on.
>

Well, I had something in mind when I wrote this... and it was not "Surely no one
will ever use this feature, then let's remove it". It was something more subtle.

I may be wrong in my interpretation, but I remember that Matz expected some
freedom of implementation of singleton method mechanism. Present mechanism is
that singleton methods are hold in a singleton class, which happens to be an
object instance of the class Class. But this may change in future version of
ruby. For example, singleton "classes" could not be a class anymore, or it could
even not be a normal object anymore. It could be anything, whatever please Matz.

Then, giving that fact as true, for the sake of future ruby versions, wouldn't
it be more consistent to forbid singleton class of singleton class?

I may admit that the such said "sake of future ruby versions" may need some
other marginal never truly used features be forbidden either. I don't know, I'm
not sure of anything.

And, please note this: I agree with you. There is nothing wrong or harmfull in
the current behavior, while looking from the point of view of a ruby user. But I
think it may be different from the point of view of a language designer and I
like to take count of it.

--
Lionel Thiry

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

dblack

5/15/2005 11:32:00 PM

0