On Jeudi, déc 4, 2003, at 01:42 Europe/Zurich, Avi Bryant wrote:

> I've just placed a 15 minute hack on SM that might be useful to some  
> people.  It allows for instance-specific behavior, or what's nicely  
> termed "singleton methods" in Ruby.  I'm interested in comments.  From  
> the SM description:
>
> --
>
> This package adds the #becomeSingleton method to Object, which will  
> transform the receiver into an instance of a new, anonymous subclass  
> of its original class.

why subclass of the original class. because now if you do
	inst class superclass you will get your normal class. This is quite  
strange.

You should have a look at my comparison  
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca99aMsgPassingControl.pdf

If I remember well in VW I did something similar, but
	I created a new behavior copied the format of the class to this  
behavior, then compile class to be superclass
	and superclass to be class superclass.

Anyway have a look this was fun.

What I would say is that these kinds of hack are fun but after to make  
them working in an integrated way
you have much more problems.


> This lets you add or redefine methods on an object-by-object basis.
>
> This is intended to be used primarily for delegation - replacing a  
> method with a block or a message send to another object.  The methods  
> #to:run:, #to:send:to:, and #delegate:to: are provided for this  
> purpose.  The following three calls are all equivalent:
>
>   x delegate: #foo: to: someOtherObject.
>   x to: #foo: send: #foo: to: someOtherObject.
>   x to: #foo: run: [:arg | someOtherObject foo: arg].
>
> In all three cases, sending #foo: to x will end up forwarding the  
> message to someOtherObject.
>
> My expectation is that this might be useful as a replacement for  
> specifying pluggable behavior with block inst vars or target/selector  
> pairs, particularly for UI classes.

Why is it really a problem?


>  Rather than explicitly putting in hooks for pluggablity, a well  
> factored object can be customized from the outside without its  
> knowledge, by overriding existing methods - particularly those that  
> are #subclassResponsibility - but without going to the trouble of  
> adding a named subclass for each use.
>
>