--1926193751-1837289603-1214088252
8942
Content-Type: MULTIPART/MIXED; BOUNDARY="1926193751-1837289603-1214088252=:18942"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1926193751-1837289603-1214088252
8942
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi --

On Sun, 22 Jun 2008, Jöòg W Mittag wrote:

> Calamitas wrote:
>> On Fri, Jun 20, 2008 at 10:48 AM, James Coglan <jcoglan / googlemail.com> wrote:
>>> What I'm trying to get at is: given that you can't really do anything
>>> 'classy' with a metaclass, it seems they could quite easily be modules
>>> instead, and this makes more sense to me as they are just objects that store
>>> methods. Why do they need to be this specific type of module (i.e. Class)?
>> I don't know why exactly --only Matz knows-- but IMO the choice is
>> somewhat arbitrary because whichever is chosen, class or module, you
>> have to take away some of its typical behaviors to have it be
>> singletonsomething. [...]
>
> Some time ago, during a discussion about the addition of a
> singleton_class method to Ruby's Core Library, Matz said that he
> didn't want to expose singleton classes that way, because he viewed
> them as a private internal implementation detail of MRI that shouldn't
> be exposed to Ruby code (and force other implementations to copy that
> detail). Not only did he view them as an *internal* implementation
> detail, he actually viewed them as a *bad* implementation detail, one
> that he wished to change. However, he said, he hadn't been able to
> come up with a better idea.

I may not have been in on that particular discussion but I always had
the impression that Matz emphasized that the main point was that Ruby
objects can adapt away from their original classes, and that the use
of singleton classes was one way to implement this but was not,
itself, the goal. I don't think they can be regarded as an
implementation detail, though, or some kind of undocumented necessary
evil, since the class keyword was always engineered to accept "<<
object".  My impression was that Matz reserved the right to move away
from the class-based implementation (there was one discussion about
the possibility of a new "class-like" object), but didn't necessarily
condemn the current way it's done.

I've always thought of the availability of a class interface to the
object's individual behavior as elegant and economical. It also makes
it relatively easy to explain singleton/individual behavior, since
it's cut from the same cloth, so to speak, as the way objects work
anyway.


David

-- 
Rails training from David A. Black and Ruby Power and Light:
   ADVANCING WITH RAILS   June 16-19           Berlin
   ADVANCING WITH RAILS   July 21-24           Edison, NJ
See http://www.rubypal.com for details and updates!
--1926193751-1837289603-1214088252
8942--
--1926193751-1837289603-1214088252
8942--