Lists Home |
Date Index |
- From: Paul Prescod <firstname.lastname@example.org>
- To: email@example.com
- Date: Wed, 16 Sep 1998 22:16:46 -0400 (EDT)
On 16 Sep 1998 firstname.lastname@example.org wrote:
> > I don't think that there is anything in the word "inheritance" that
> > implies an is-a relationship, though I agree that sometimes it is used
> > that way.
> "Sometimes" meaning rarely, or "sometimes" meaning almost always, but
> I'm not ready to concede the point? (I, too, can split hairs! ;-)
"Sometimes" meaning "usually, even though it obfuscates, like using 'tag'
to mean element type, GI, attribute and tag'." Another way to express the
difference is "type inheritance" vs. "implementation inheritance".
I don't like that terminology, because it perpetuates the idea that they
are the same thing.
> Inheritance and subclassing are both about substitutability.
How is C++ private inheritance (for example) about substitutability.
> I think
> it would be fair to say that inheritance has _almost always_ been
> associated with wholesale borrowing of the structure of the thing
> being inherited from, either through copy or reference (through
I agree. Borrowing of structure, not necessarily interface.
> The exceptions, like C++'s private inheritance, are at
> the margins. In what language that you are aware of does inheritance
> or subclassing not imply substitutability?
Well, you mentioned C++, but another is Sather. Dynamically typed OO
languages usually allow the distinction also. In Python, Smalltalk,
etc., interfaces are described implicitly. In Python, at least, you can
inherit and yet violate the interface of your superclass by deleting
Here's info on Sather:
"Separate Implementation and Type Inheritance
In most object-oriented languages inheritance both defines the subtype
relation and causes the descendant to use an implementation provided by
the ancestor. These are quite different notions and confounding them
often causes semantic problems. For example, one reason why Eiffel's type
system is not statically checkable is that it mandates "covariant"
conformance for routine argument types (Meyer, 1992). This means that a
routine in a descendant must have argument types which are subtypes of
the corresponding argument types in the ancestor. Because of this choice,
the compiler cannot ensure argument expressions conform to the argument
type of the called routine at compile time. In Sather, inheritance from
abstract classes defines subtyping while inheritance from other classes
is used solely for implementation inheritance. This allows Sather to use
the statically type-safe contravariant rule for routine argument
> > XML element types have three interesting properties: content models,
> > attributes and GIs. So to me, "inheritance" between element types would be
> > about borrowing some or all of another element types content model,
> > attributes or GIs.
> If you only borrow some, you lose substitutability.
That isn't true. For instance, you can clearly supply your own content
model without disturbing substitutability, as long as it is a compatible
content model. The model can describe a sub-language, or it can describe
a superclass language that can be converted into some sublanguage.
>If you want to
> borrow without substitution, just use pe's. You haven't gained
> anything semantically interesting.
Structured, portable, explicit code (declaration) reuse is not
interesting? I strongly agree that "implementation" inheritance is not as
interesting as type inheritance in markup languages. But I think that
clearly "expressing intent" with respect to content model reuse is also
Note that I think that this "implementation inheritance" is
what most people mean when they say that XML "really needs inheritance."
It is a demonstration of your clear understanding of the issues that you
recognize that there is a much bigger picture than declaration reuse.
If you, or anyone else, proposes a schema language with subtyping but
not inheritance, I would probably support it if it was done right. If
someone proposed the opposite, however, I would argue that it is not much
of an improvement.
> > Subclassing, on the other hand, would be about having an element of one
> > type "play the part of" an element of another type, such as a
> > cross-reference "playing" an XLink.
> Inheritance means playing the part of the element you are inheriting
> from (with a nod towards awkward exceptions at the margin).
Type inheritance, yes. Inheritance "in general", no. The word inheritance
is vague and any property of one type could be inherited by another if a
language allows it. There is no reason that all of the various types of
inheritance should be tied together just because that is often (but not
always) useful. It costs nothing to separate them, and buys power and
expressiveness: the ability to specify intent.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)