"Singletons" package on SM
ducasse
ducasse at iam.unibe.ch
Thu Dec 4 08:17:33 UTC 2003
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.
>
>
More information about the Squeak-dev
mailing list
|