>
>> 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.
>
> Ah, I may now understand your objection better - what you were doing  
> in your paper was trying to affect an entire class of objects at once,  
> transparently.    I'm trying to affect a single instance, and it  
> doesn't need/want to be transparent.  I'm not using the existing  
> lookup mechanism to hack in new semantics (like my Mixin  
> implementation does, for example), I'm really just trying to introduce  
> a new way of defining subclasses (that happen to have exactly one  
> instance).

No read it well I can have instance based behavior!


>
>> 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.
>
> Again, for my goal (anonymous, instance-based subclasses), I don't  
> think any further integration is really needed (well, it might be nice  
> to show the singleton methods in the Inspector, but that's really  
> minor).  It's not a hack in that sense - I would have no qualms using  
> this in production code (I think - maybe someone can convince me  
> otherwise).  I think the main integration problems would come if you  
> were introducing new CompiledMethods with source code into these  
> subclasses, but since I'm using MessageSends and blocks (through  
> Andreas' ObjectsAsMethods stuff, but could also be MethodWrappers),  
> there are no ugly calls to #compile: or anything.
>
>>> 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?
>
> Two things.  One is the idea of "unplanned reuse", which I think  
> Smalltalk generally excels at: if you have well factored code, it's  
> often very easy for someone to come along later and introduce a  
> subclass where you had no idea that someone would want to change the  
> behavior you started with, simply by redefining a few key methods.   
> However, this kind of reuse is only possible through subclassing - to  
> reuse code through composition, the developer has to have left you  
> explicit "pluggable" hooks.  Since I think composition is often a  
> better solution than subclassing in other ways, I think this is a  
> shame.  This puts subclassing and composition on equal grounds in that  
> respect.
>
> Second, it's very common for someone to build in extensibility in two  
> ways (subclassing and composition) by having an abstract class that  
> defines a #subclassResponsibility, have some concrete classes that  
> fulfill this responsibility, and then have a Pluggable subclass that  
> allows the user to supply a block to fulfill the responsibility  
> instead.  An example close to this is Set, IdentitySet, and  
> PluggableSet.  With this delegation code, someone just has to mark the  
> extensibility points once with #subclassResponsibility, and that same  
> responsibility can either be fulfilled by an explicit subclass, or by  
> an anonymous instance-based subclass (ie, through composition), with  
> no need for the boilerplate of a "Pluggable" version.  And note that,  
> like Traits, this approach may remove the need for copied code in  
> IdentitySet and IdentityDictionary - instead, you would have a  
> separate IdentityScanner class that implemented the revised #scanFor:,  
> and to make a Set *or* Dictionary into an Identity[Set|Dictionary],  
> you could say
>
> collection delegate: #scanFor: to: (IdentityScanner for: collection).
>
> Or something along those lines.  Hmm... to achieve this otherwise you  
> would need the hierarchy
>
> Set
>   PluggableSet
>      Dictionary
>
> which is ugly for all kinds of reasons (including performance ones).   
> So even if you *are* planning for this kind of reuse, the block  
> pluggability still looks like it's worse.  (Ok, having realized that,  
> I ought to rewrite this argument to be based entirely around that  
> example, but it really is late so I'll let the rambling stand).
>
> Cheers,
> Avi
>
>