OO Schemas

[Paul Prescod]

On 16 Sep 1998 matt at veosystems.com 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".

http://www.neurop2.ruhr-uni-bochum.de/personal/cozzi/sather-style_toc.html#SEC42

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.

http://hpsalo.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/WM/WM_23.html

> 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
> delegation).  

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 
methods. JavaScript is the same. I don't know if there is a way to do it 
in Smalltalk.

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 
conformance."



> > 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
important. 

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.

 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)