From: dblack@...
Date: 2006-08-30T05:17:35+09:00
Subject: Re: Singleton classes and methods (was Re: Reformat Ruby source code in vim?)

Hi --

On Wed, 30 Aug 2006, Rick DeNatale wrote:

> On 8/29/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> Hi --
>> 
>> On Wed, 30 Aug 2006, Rick DeNatale wrote:
>> 
>> > If a singleton class is a class which is tied to one and only  one
>> > object, then a singleton method should be a method tied to one and
>> > only one object as well, but check this out:
>> >
>> >  class X
>> >       def foo;end
>> >  end
>> >
>> >  X.singleton_methods => ["foo"]
>> >
>> >  class Y < X; end
>> >
>> >  Y.singleton_methods => ["foo"]
>> >
>> > Does anyone beside me find that surprising?
>> 
>> It's always struck me as an anomaly.  It's redeemed somewhat by the
>> superclass thing, whereby class << X is the superclass of class << Y.
>> (At least, in 1.8.2 and > 1.8.5 it is; I'm not sure why that got
>> derailed by 1.8.4, since it still behaves that way.)
>
> So was there a change in 1.8.3 which got backed out in 1.8.5?
> What was it?

It's only changed in 1.9, I think (hence "> 1.8.5").  In 1.8.2 you get
this:

rubypal:~$ /usr/local/lib/ruby-1.8.2/bin/irb
irb(main):001:0> class A; end
=> nil
irb(main):002:0> class B < A; end
=> nil
irb(main):003:0> class << A; object_id; end
=> -604523004
irb(main):004:0> class << B; superclass.object_id; end
=> -604523004

I'm not sure about the negative object id numbers... but basically A's
singleton class is the superclass of B's singleton class.

In 1.8.4 the numbers are different.  But the basic arrangement --
namely, that B can call A's singleton methods -- is still the same.

In recent 1.9's they're back to being the same object.

[...]

>> > I just realized that there's no class_methods family of methods in
>> > Ruby.  I can't say:
>> >
>> >  Array.class_methods
>> >
>> > instead I have to say:
>> >  Array.singleton_methods
>> 
>> Now that's the cool part :-)  I love the fact that there's no
>> language-level notion of a "class method".  In general, Ruby has this
>> way of providing a remarkably featureless (I use the word advisedly)
>> landscape, out of the featurelessness of which one can mold features.
>> So if you feel like there should be class methods, you can tap into
>> the fact that class objects can have singleton(ish) methods.  But as
>> far as Ruby is concerned, there's no special case.
>
> Well Module does have methods  private_class_method, and public_class
> method, to "make existing class methods" private or public
> respectively, so there does seem to be some notion of "class method."

So it does.  Ugh.  Oh well :-)  I still tend to see that as layered on
top of what's really going on.

>> > While I can say
>> >  Array.private_instance_methods
>> >
>> > How do I get the private_class_methods?
>> 
>> class << Array; private_instance_methods(false); end
>> 
>> or something along those lines.
>
> Well, you'd think, but not quite:
> class <<Array;private_instance_methods(false);end
> => ["inherited", "initialize", "initialize_copy"]
>
> Which are the private instance methods of the class Object?!

That also seems to have been a deviation in > 1.8.2 < 1.9:

irb(main):003:0> RUBY_VERSION
=> "1.9.0"
irb(main):004:0> class A; end
=> nil
irb(main):005:0> A.private_instance_methods(false)
=> []


David

-- 
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby Central, Inc.   [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org