Multiple Inheritance

Wouldn’t be Spoon and Fork be subclasses of Spork?

My recollection is...

It was about how to classify objects (kitchen utensils in this case). She asked the class to name all the utensils they could think of. Each was written on an index card. http://en.wikipedia.org/wiki/List_of_food_preparation_utensils. She asked for ideas about how they might be classified (by material, use, location of use, stage of use, context of use, etc.). There was discussion and disagreement of course. Attributes of each were added to each card. The attributes helped some (by defining a classification epistemology). Though classification rules were now defined, utensils still failed to be conform in a way that supports single inheritance. Would a "spork" be  a kind of fork or spoon? With SI, you can only pick one. Should a new kind of abstract utensil class be created to accommodate the spork? Still then, what is the superclass of a spork? Neither would be ideal and behavior for the other class would have to be copied to the Spork.

This is when she introduced the notion of multiple inheritance and that Smalltalk doesn't have it (C++ started to seem cool for a moment). But what could be done for Smalltalk though? The answer was to define a hierarchy of responsibilities (each with attributes and behavior). A Spork would then be defined as a combination of responsibilities/abstractions that were bridged together and yet still behaved as a class for which instances could be created. Spork was neither a subclass of fork nor spoon but shared the same superclass. The hierarchy of utensil classes could become shallower and more manageable as two separate hierarchies. Separation into two hierarchies of responsibility (that are bridged together) was more maintainable than a pure MI approach. All that Smalltalk needed was a simple framework to allow classes to be defined as a mixture of the behavior of other classes.

A mixin framework can be described as support for the automatic maintenance of mixed-in responsibilities to reduce the redundancy that normally evolves from SI. A mixin framework is a tool to help a developer increase code reuse and reduce code maintenance costs.

I had set about to implement a framework to make this easy to manage. At first I called it a Multiple Inheritance framework. Then later renamed code to use either "mixin" or "pidgin" once I saw that those terms seemed to have already been established for use in other languages. The terms were not familiar to many though. Delegation of behavior was the easy part to implement; the trickier issues were around attribute implementation and preservation of "self". I used template compiled methods that were copied with modification directly into the method dictionary. In one implementation, "self" was preserved through #== checks on the results from forwarded messages. The sequence of inherited behaviors defined behavior inheritance priority. If Spork was defined with responsibility of first Spoon and then Fork then a common method like #printOn: would by default to that of Spoon. Spork could of course define #printOn: a more appropriate way while still being able to explicitly call the behavior inherited from Spoon or Fork. I'd experimented with other implementation variations too (things like associated attributes and automatic local copies of behavior). An implementation I settled on had an array of instances of inherited responsibilities for which methods were configured to access the correct index position. It was the responsibility of the framework to automatically keep all inherited behavior and references in sync as code evolved. It worked well, but had tricks so that code management tools like ENVY would not get confused. Another tricky area was in related to inheritance from classes (like Date and Float) that aren't created (and initialized) like most other objects.

The idea at the time was to encourage Smalltalk vendors to adopt an implementation as standard. That started to happen but those that developed interest always wanted to start their own implementation from scratch and just did the #doesNotUnderstand: tricks alone and later gave up when preservation of "self" became recognized as a challenge. That was one of my first experiences with attempting to help evolve the Smalltalk language. The cultural challenges never got much better. For better and worse, Smalltalk is a closed language that evolves or dies by the choices of a few vendors and from the inspiration of a few employed by those vendors. Lacking a market that could develop a financial incentive, the only motivation that exists for frameworks like this is personal pride of accomplishment. That is why every Smalltalker "re-invents the wheel" and also why really good frameworks rarely get shared or used. Smalltalk development is a culture of one.

GS/S and now VisualWorks have the ability to associate state directly to instances (without the traditional trick of weak reference lookup tables). Features like this can make for more efficient mixin frameworks that can preserve "self" easier than the ones I'd implemented. Hopefully someone will leverage this new feature to establish a good mixin framework that we will all use.

Paul Baumann

On Fri, Jun 8, 2012 at 9:31 AM, Paul Baumann <[hidden email]> wrote:

--

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.

Sure, if you want to disable (or ignore) Spoon-specific behavior in Fork and and Fork-specific behavior in Spoon. Some senders of #shouldNotImplement could be examples of that kind of inheritance. Lots of ways to do it. Most subclasses try to add rather than subtract, but exceptions are acceptable. Likewise, most would prefer "c = a + b" over "a = c - b" because the nature of a, b, and c are expressed in a more elemental and intuitive way. I posit that subtraction and division in an equation can suggest adjustment for a classification error. An inheritance structure that subtracts can have valid behavior but to me it suggests classification problems.

Rebecca's utensils example was good for showing challenges but I can't really think of what instance variables and methods I'd want to define on any utensil. What scenario would I want to create an instance of a Spoon and know how it differs from a Fork? It would have to be some form of environment modeling where a spoon instance has position, mass, dimensions, velocity, material, temperature, etc. and this spoon differs from standard in that the handle is bent.... If the instance could accommodate knowledge of a bent handle then what about other modifications like discoloration, cuts, temperature differences, electron flow, etc. At some point it is realized that "the spoon does not exist" meaning that the spoon is a configuration of materials that make it appear as a classification people simplify to their personal notion of a spoon. A general definition of a spoon is of little value in this modeling environment as the understanding of a spoon is personal. To one person, the handle of a spoon will open a paint can as well as a the handle of a fork. To another person, a tea spoon is a better choice for use for a specific purpose. "Spoon" is a common classification of an object for the purpose of communication between actors in that environment. The spoon does not exist to the modeling environment but it exists according to the understanding of each actor in the environment. The understanding of the spoon is subjective but to objective classification rules that are subjectively acknowledged. The value of a "spoon" is a reflection of the personal understanding of how an actor may use it. An atom is a relatively consistent arrangement of electrons that are subject to expansion (sorry that differs from the common understanding of the internal structure of the atom). A "spoon" to the physical world is an arrangement of atoms. The first level of classification of that "spoon" is which atoms are considered to be part of that arrangement. One can classify the relationships between Spoon, Fork, and Spork any many ways and still be successful (defined by favorable interaction). The classification is for ease communication. Classifications evolve as sporks and platypus are recognized. The Natural Law is that classification choices are dynamic and personal.

In other words, sure, one can argue a Fork a kind of Spork just as well as another could argue that is is not. It would be an argument over subjective minutiae that communication more than the value that the spork can bring to an actor.

Paul Baumann

Wouldn’t be Spoon and Fork be subclasses of Spork?

GS/S has always had #tagAt: and #tagAt:put: but it was limited to two attribute slots per object. This can be useful for example for an object to know what indexes it is involved in without having to add an 'indexes' instance variable to every class (and instance). Newer versions of GS/S basically extend this idea to give an infinite number of named tags (dynamic instance variables) that can be used by each object.  The instance variables are closely associated with each object just as a normal instance variable (with respect to garbage collection and such). These dynamic variables do not need to have a slot allocated in memory for every instance. They don't need to be visible in object inspectors either.

Look at #myDependents in VW for an example of dynamic associated attributes. Object>>myDependents uses a lookup table to find the dependents associated with an object. Subclasses that commonly have dependents that override #myDependents to use an instance variable that they define. In other words, all objects have #myDependents to varying levels of need and efficiency.

GemBuilder for Smalltalk (GBS) allows transparent access to automatically maintained state in either the VW image or GS gem. In order to do this it needs to be able to associate a GS delegate object to each real VW object and then coordinate changes through caches. Those caches need to have weak references to the object that the delegate is affiliated with so that the VW image can release objects (and delegates) no longer needed. The caches are identity hashed collections that are subject to identity hash limitations (which is a serious performance problem). When you can associate the GS delegate to objects without using the identity cache then you can greatly improve performance (actually you need to associate an oop cache association that knows the delegate, but I won't get into those details). The point is, this is another use of dynamic instance variables.

Shouldn't such a cool trick of dynamic instance variables have general availability? If it did then GBS and other frameworks wouldn't have to implement their own lookup caches and later deal with the details of weak array finalization.

I was pleased to hear that dynamic instance variables are coming to newer versions of VW. It open a whole new world of possibilities and performance for those that have had to use identity-based associative indexes. I've only heard the announcement (at the last STIC conference) that VW will have them, I don't know what Cincom is calling them or what releases they are part of. If done right, it will be a big opportunity for frameworks that wish to extend the attributes of each object (for the needs of the framework) without modifying the class definition.

Paul Baumann

Obliged if this can be elaborated on:

Usually you do not have black/white classifications but all shades in between: utensils with spoonishness and forkishness. Whether or not it is used as (materializes?) a spoon or fork depends indeed on the situation/context.

Sure, if you want to disable (or ignore) Spoon-specific behavior in Fork and and Fork-specific behavior in Spoon. Some senders of #shouldNotImplement could be examples of that kind of inheritance. Lots of ways to do it. Most subclasses try to add rather than subtract, but exceptions are acceptable. Likewise, most would prefer "c = a + b" over "a = c - b" because the nature of a, b, and c are expressed in a more elemental and intuitive way. I posit that subtraction and division in an equation can suggest adjustment for a classification error. An inheritance structure that subtracts can have valid behavior but to me it suggests classification problems.

Rebecca's utensils example was good for showing challenges but I can't really think of what instance variables and methods I'd want to define on any utensil. What scenario would I want to create an instance of a Spoon and know how it differs from a Fork? It would have to be some form of environment modeling where a spoon instance has position, mass, dimensions, velocity, material, temperature, etc. and this spoon differs from standard in that the handle is bent.... If the instance could accommodate knowledge of a bent handle then what about other modifications like discoloration, cuts, temperature differences, electron flow, etc. At some point it is realized that "the spoon does not exist" meaning that the spoon is a configuration of materials that make it appear as a classification people simplify to their personal notion of a spoon. A general definition of a spoon is of little value in this modeling environment as the understanding of a spoon is personal. To one person, the handle of a spoon will open a paint can as well as a the handle of a fork. To another person, a tea spoon is a better choice for use for a specific purpose. "Spoon" is a common classification of an object for the purpose of communication between actors in that environment. The spoon does not exist to the modeling environment but it exists according to the understanding of each actor in the environment. The understanding of the spoon is subjective but to objective classification rules that are subjectively acknowledged. The value of a "spoon" is a reflection of the personal understanding of how an actor may use it. An atom is a relatively consistent arrangement of electrons that are subject to expansion (sorry that differs from the common understanding of the internal structure of the atom). A "spoon" to the physical world is an arrangement of atoms. The first level of classification of that "spoon" is which atoms are considered to be part of that arrangement. One can classify the relationships between Spoon, Fork, and Spork any many ways and still be successful (defined by favorable interaction). The classification is for ease communication. Classifications evolve as sporks and platypus are recognized. The Natural Law is that classification choices are dynamic and personal.

In other words, sure, one can argue a Fork a kind of Spork just as well as another could argue that is is not. It would be an argument over subjective minutiae that communication more than the value that the spork can bring to an actor.

Paul Baumann

Wouldn’t be Spoon and Fork be subclasses of Spork?

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.