"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