Talents: Dynamically Composable Units of Reuse

Talents: Dynamically Composable Units of Reuse by Jorge Ressia, Tudor Gîrba, Oscar Nierstrasz, Fabrizio Perin, and Lukas Renggli. Proceedings of International Workshop on Smalltalk Technologies (IWST 2011), p. 109—118, 2011.

Reuse in object-oriented languages typically focuses on inheritance. Numerous techniques have been developed to provide finer-grained reuse of methods, such as flavors, mixins and traits. These techniques, however, only deal with reuse at the level of classes. Class-based reuse is inherently static. Increasing use of reflection and meta-programming techniques in real world applications underline the need for more dynamic approaches. New approaches have shifted to object-specific reuse. However, these techniques fail to provide a complete solution to the composition issues arising during reuse. We propose a new approach that deals with reuse at the object level and that supports behavioral composition. We introduce a new abstraction called a talent which models features that are shared between objects of different class hierarchies. Talents provide a composition mechanism that is as flexible as that of traits but which is dynamic.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

that's an interesting object model

I'll summarize parts of the paper I grasped, then note how it relates to something I'm pondering (some kind of theory of affordances).

I gather a talent is a like a per-object class, used for dynamic per-instance behavior extension and editing (including removal of old behavior, likely subverting law of demeter, which I don't mind). In classic Smalltalk, an object sent a message looks for the method in the object's class, so an object's scope of behavior is static if its class cannot change and the class's methods cannot change. Behavior is in the class, and each object has one class (subsuming all inherited classes one way or another), so all instances of an object type have the same class and thus the same behavior.

Adding per-instance object behavior, via one or more talents, alters dispatch to find behavior in the talents as well as the object's class. Methods are in the same namespace so a talent can override inherited class methods, or remove them or rename them. Namespace conflicts among multiple talents are resolved by explicitly disambiguating names, including by name change to an alias. The result is dynamic behavior varying between instances and over time, both. Given instances A, B, and C, if you debug their past behavior you'll have to determine things they could have done at different moments in time, if they briefly had a talent for it.

If you imagine methods known by an object instance as gathered in layers, each layer like a transparency listing methods from a class or talent, then scope of behavior for one instance is whatever it can see in the merged transparencies (but where a layer on topic can edit a lower one). Talents might all belong to one flat layer on top though, without stacking.

Sounds interesting but chaotic: extremism in dynamic typing. I'd hate to debug it, but I like it as a use case for thinking about any system analyzing what can happen.

I have this really half-baked idea cooking in the back of mind, and talents seem tangentially related to the extent they edit affordances. But I'm not even sure affordances is a central aspect. There's a whole bunch of topics, like push-vs-pull and inversion-of-control, that seem related to me at the moment. I think I got started on this train of thought by trying to decide whether all systems were event oriented, if you took advantage of duals to prefer an event perspective in each case. Everywhere a producer and consumer hand off signals, however coded, they had to find each other and be willing and able to rendezvous in a transaction. I was trying to imagine writing docs about what it means when you transform stand-alone programs into lightweight processes, especially if you create pipelines and coroutines. Blocking is like saying, "Send me an event when I can keep going." So you can see where I got the event-oriented focus. I feel like I'm untangling a ball of yarn. Not sure if it's meaningful.