"Inheritance considered harmful"

Paul Prescod papresco at technologist.com
Thu Apr 2 22:08:33 BST 1998

On Thu, 2 Apr 1998, W. Eliot Kimber wrote:
> That's probably because the architecture facility of ISO/IEC 10744 doesn't
> *do* inheritance in the way that most people seem to expect.

That's right. That's why people get so confused about them. The word 
inheritance is inherently misleading when applied to architectural forms.

Architectural forms do subtyping, not inheritance. Inheritance is about
"getting stuff for free"  (e.g. code, declarations, fields). Subtyping is
about *fulfilling a particular role* (perhaps through a manual
construction of an appropriate "interface" (in this case a content
model)). Architectural forms allow you to specify an interface that must
be fulfilled and declare conformance to that interface. It does not allow
you to "get code for free" (i.e. markup declarations). 

When I inherit from my father, I get his money without doing any work. I
get to live in the same house he lived in without redoing everything he
did to get it (not that I've had this experience...yet <evil grin>).  But
When I subclass from the class "husband" I agree to do things like be
faithful and caring and so forth. They are very different things. I have 
to put forth effort to fulfill that role.

It's easy to get them confused, because there are benefits that accrue 
from fulfilling any role, and you may think that you are "inheriting" 
those benefits, but really, you are just getting them because you 
fulfilled the terms of the "contract." In SGML terms, when you subclass 
from an architectural DTD you get the benefit of all of the great 
software that has been written to handle that DTD. But you didn't inherit 
it -- it's just your reward for fulfilling the contract.

The word inheritance is vaguely defined, because it depends a lot on 
context. Parameter entities allow us to "inherit" declarations that might 
have been created for some other document type. So SGML has inheritance 
at some very large grain, but what people usually mean when they ask for 
inheritance is fine grained element/attribute level inheritance, which is 
more tricky (and perhaps when push comes to shove not as valuable as it 
might seem -- there are other ways to achieve reuse).

Subtyping, on the other hand, is quite mathematically defined, and it 
seems clear to me that this is what people mean when they say that 
architectural forms allow inheritance. Here is subtyping in a nutshell:

A type is a set of objects.
A subtype is a subset of that set of objects.

An architectural form describes a set of elements or documents that can 
be transformed into a particular language defined by the architectural 
DTD. It defines an "element" or "document type" in the philisophical sense.

A derived DTD or archform describes a subset of those elements. It 
defines an "element" or "document" subtype.

Using the word inheritance to describe this relationship can only 
obfuscate things. This sort of subtyping relationship exists in hundreds 
of places in computer science, the physical world and logic and it is 
*not described as inheritance*.

Here's a simple example. Python code can be compiled to JVM bytecodes. 
This is really cool because Python programs can be shipped across the net 
like Java, but Python is much easier to program in, and much faster for 
prototyping. Does Python inherit the ability to be shipped across the net 
from the JVM bytecode specification? No. It conforms (after a 
transformation) to the JVM byecode specification format and thus it gets 
JVM execution "for free."

Does it subtype the JVM bytecode format? Yes, after a transformation it
does. The set of all Python programs is a subset of the set of all 
programs that can be transformed into something that will run on the JVM.

 Paul Prescod

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

More information about the Xml-dev mailing list