From: Lionel Thiry <lthiryidontwantspam@...>
Date: 2005-05-16T11:30:31+09:00
Subject: Re: infinite number of singleton_classes

David A. Black a �crit :
> On Mon, 16 May 2005, Lionel Thiry wrote:
> 
>> You have skipped this part of my post in your answer:
>> ----8<----
>> 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.
>> ----8<----
> 
> 
> I didn't have anything to add to it, so I didn't quote it back.
> Otherwise we get into infinite recursion :-)
> 
>> The feature is currently avaible, but unless Matz state otherwise, it
>> is an
>> accident, it shouldn't have never happened. Why? Because it may
>> disapear in any
>> future version of ruby. Who said it? Matz himself. It then should be
>> accessible
>> only via special module like evil.rb if one really want the feature.
> 
> 
> If it disappears, it can't be accessible from any module, at least not
> in exactly that form.

I should have added "Until it disapears (if it disapears), it should be
accessible only via...". Sorry.

> 
>> On the other hand, if it was said that ruby won't never change about
>> singleton
>> methods hold in singleton classes, I wouldn't care at all about this.
> 
> 
> There's a bit of a paradox there.  If Ruby shouldn't contain anything
> that might be absent in a future Ruby, then Ruby today must be exactly
> what Ruby in the future will be....  If singleton classes disappear,
> lots of things will change, possibly including:
> 
>    class << obj     # this form of the class keyword
>      X = 1          # constants -- where would this go?
>      def self.x     # class methods on the singleton class
>      end
>    end
> 
> as well as just the fact that you can call Class's instance methods,
> in general, on singleton classes.
> 
> So if you apply the rule: it should never have happened because it
> may disappear in a future version of Ruby, then all of this should
> never have happened and should disappear.  But so should lots of other
> things, because Matz is planning lots of changes.  So that means Ruby
> should be turned into future Ruby *now*.  But that takes time :-)
> 


My "why?" argument was insuficiant, I admit it. Sorry.

Future version of ruby will change... but the ruby way/feeling will not. This is
the garantee Matz has given us for ruby2, AFAIK. And IMO I think the presence or
the absence of that feature matters a lot for defining that ruby way.

For example, the fact that
----8<----
 class << obj
  X = 1
  def self.x
  end
 end
----8<----
could disapear implies a lot on the ruby way.

-- 
Lionel Thiry

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