From: Ned Konz <ned@...>
Date: 2001-08-15T01:38:59+09:00
Subject: [ruby-talk:19708] Re: Why not?: Assigning to self

On Tuesday 14 August 2001 09:27 am, you wrote:
> >>>>> "N" == Ned Konz <ned@bike-nomad.com> writes:
>
> N> How else would you do it in Ruby?
>
>  Personnaly I don't see the utility to change the class of an object from
> Array to Hash (for example), now if you can give me rules for the changes.

This is why become() is better than providing an arbitrary ability to change 
the class of an object. Clearly, since Ruby provides data inheritance as well 
as method inheritance, it makes no sense to take an existing object and 
change its class.

When one uses become() to swap the identities of two objects (or 
oneWayBecome() to substitute one object for another), one assumes the 
responsibility of making sure that these objects are indeed substitutable: 
that their interfaces are compatible.

In the cases where become() makes most sense, the interfaces of the two 
objects in question are, in fact, identical.

This is why I gave the example of changing a proxy into a real object. The 
proxy and the object it's proxying both would have identical interfaces.

In other cases (speaking in class terms), become() would be used two swap two 
objects that share a common superclass, or to change an object into an 
instance of a subclass of the original object's class.

Ruby is not free from implied interface constraints. Creating singleton 
classes generally implies that the new behaviors will be compatible with the 
superclass behavior. 

-- 
Ned Konz
currently: Stanwood, WA
email:     ned@bike-nomad.com
homepage:  http://bike-nomad.com