From: Sean O'Dell <sean@...>
Date: 2004-06-28T07:13:28+09:00
Subject: Re: Is it considered Harmful?

On Sunday 27 June 2004 14:48, Patrick May wrote:
> On Sunday, June 27, 2004, at 05:20  PM, Sean O'Dell wrote:
>
> > Of course, like I said, the Ruby internals make difficult to make a
> > stable
> > feature, so the point is probably moot.  But what I found interesting
> > was how
> > easy it was to change an object's class in C, and to provide a fair
> > amount of
> > protective code by simply adding a Check_Type call to the R* macros.
>
> Protecting Ruby from a segfault is not going to insure that all
> changling objects work properly.
>
> How can any class, not just the Ruby internals, make an intelligent
> decision about how to initialize an instance from a random operand?

Well, I think the rule here is: buyer beware.  The only real use for class= 
would be when you are replacing one class with another that KNOWS and 
UNDERSTANDS that it's a replacement class, and behaves appropriately.

> solve this problem, but this is poor encapsulation.  For #become to be
> safe and easy, every class has to know details of the internal state of
> every other class.

A class only has to check its own internal data, not know and understand 
everyone else's.  If it can't find its own internal data, or the internal 
data is clearly of a type belonging to some other class it doesn't know 
about, it should degrade gracefully by throwing some kind of "bad internal 
data" exception.

> Again, why should every class be saddled with the responsibility of
> knowing the internal semantics of literally *every* other class in the
> system?  Those #update_instance_for_changed_class methods keep getting
> larger and larger....

It shouldn't; it should only know about its own data, and ignore everyone 
else's.

> #become / #class= is an interesting thought experiment, but it becomes
> absurd when I imagine what it would take to make it work properly.
> These methods shift a responsibility that is easiest to handle outside
> a class into somewhere it doesn't belong.   That is ugly, difficult,
> and not Ruby-like IMHO.

The internal Ruby code, in a lot of places, assumes the type of object that 
self points to.  This kind of assumption is the one that brings out the 
crashes.  This is the real hurdle.  If every internal checked its own self 
type before trying to use it, and degraded gracefully when it doesn't have 
the right internal data, this feature would be perfectly safe.

Writing classes that understand the internal data of other classes is up to 
the developers themselves.  For the most part, you couldn't set the class of 
a File object to a Hash and expect much to happen except for "bad internal 
data" errors.  However, someone could develop a class that understands the 
internal data of the File object and it would be perfectly safe to replace 
File object classes with the new class.

	Sean O'Dell