Delegation In Smalltalk

Discussion about DelegationInSmalltalk moved from DelegationIsInheritance.

Here's a case where the pragmatics make all the difference. They may be duals but using them in a particular language is a completely different experience. In java or c++ for example, inheritance are parts of the language and are easy. Delegation are not part of the languages is extremely difficult to maintain. I've gone the delegation route and decided against until it is directly supported in the language.

Which is a concise and clear example of why some of us prefer environments like Smalltalk and Lisp. The "pragmatics" of java or C++ is that the shortsighted constraints of the language block access to large and important areas of work. I feel compelled to add that delegation is actually not that hard to do in Java. Which highlights the perception of inflexibility even more starkly.

Hardness is a personal decision. Anything that requires constant maintenance with each change is hard in my book, maybe not in yours. Since when does smalltalk have delegation? Since the moment that anyone who desires it adds it, by extending the metastructure. It can be added to Java, but the hoops to jump through are smaller and higher.

[His point about Lisp and SmallTalk is that they are mutable, you can extend them to do whatever you like, adding delegation would be easy in those languages if you thought the concept worthy, while C++ and Java don't give you that power, you're stuck with the concepts already built into the language.]

How would it be easy in smalltalk? And what would it matter unless all of smalltalk was built with delegation in mind? That's the key for a language feature. Anyone can add anything they like to a language via preprocessors and other means, but unless the ideas are used synergistically through the whole language and libraries and applications, it's just a hack.

My first thought would be to add protocol in Behavior, Object, and maybe DoesNotUnderstand. Look at the literature to see how older Smalltalk systems simulated multiple inheritance. The ideas don't need to be "used synergistically through the whole language and libraries and applications", they need to be available to new libraries and applications that want them. Remember that in Smalltalk, adding a new method to Object makes it available to every instance, including existing instances. So your new behavior is available throughout the environment.

[Yea, what he said. Adding delegation is a meta task, SmallTalk has a rich meta model. Maybe a real SmallTalker? could jump in here and help me out, I've only studied it learning purposes. But as far as I know, you just change the way methods are called in the Behavior class, it's not a hack, since you can do it for your meta class and only have it apply to your objects, or to the whole system. Preprocessors are no comparison to a real meta model in the language. Meta programming in SmallTalk isn't a hack, it's the norm.]

For what it's worth, SqueakSmalltalk already has a couple of different implementations of SelfLanguage-style delegation. (One is pure Smalltalk; the other adds a couple of bytecodes to the VM for performance reasons. Neither implementation is particularly complicated.) Try installing the "Squeak Prototypes" package from SqueakMap, if you're interested.

Nobody really uses them much, though, as far as I know - not even the Squeakers who know Self and like it (and there are a few of those, including me). I can't speak for anyone else, but the reason I don't use them is partly because of lack of tool support (Squeak's tools kinda assume that everything fits into the Smalltalk class/instance worldview), and partly because I value uniformity (I'd rather have a system that's all Smalltalk than a system that's a mishmash of Self and Smalltalk, though I wouldn't mind living with the non-uniformity temporarily if it's just for the sake of allowing a gradual transition).

So, yes, it's cool that Smalltalk is rich enough to be able to do these kinds of experiments (and I'd hate to live in an environment that wasn't), but to really do this particular experiment properly, you'd need to make some changes to the tools. (I've got some ideas along those lines, but I never seem to have time to implement them. :) Beyond that, you can decide for yourself whether you value the new feature enough to be willing to give up uniformity.

-- AdamSpitz

You could also enhance the tool support, since the source is available in the environment. Smalltalk is whatever you want, or need it to be. That's what makes it so cool, there are no barriers, your only limitation is you.

See also TrickySmalltalkProblemSolved for some good advice about double dispatch. (Or is there a better page to link this from?)