[
Lists Home |
Date Index |
Thread Index
]
Your assertion implies a naïve view of OOP. There are many examples in the various class libraries that I have used of classes that could not withstand changes to their subtypes without serious breakage occuring in applications. Why else do you think the java.lang.String or System.String classes in the Java platform and the .NET Framework respectively are final/sealed?
I can rattle of a number of Java and .NET framework classes where subclassing them and overriding a few key methods would cause significant breakage to apps that process the base type. This is even worse when you throw interfaces into the mix, try passing an Oracle XDK implementation of the org.w3c.dom.Element interface to one expecting a Excelon implementation and see how many apps can withstand the change.
The main difference is that we've been practicing OOP for years and now know how to utilize classes in a manner that avoids breakage. That's why I said I'll hold my judgement until type aware processing of XML becomes widespread.
PS: Sorry for the brusque email, I'm late for dinner. :)
--
PITHY WORDS OF WISDOM
In any contest between power and patience, bet on patience.
This posting is provided "AS IS" with no warranties, and confers no rights.
-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]
Sent: Monday, September 02, 2002 9:20 PM
To: xml-dev@lists.xml.org
Let me try to summarize the problem with XML Schema inheritance this
way: The defining characteristic of subtyping in OO languages is that if the subtype is properly designed it *will not break code* written for the supertype, whether the supertype predicted your extensions or not.
This can be achieved with XML Schema inheritance only if the people writing code for the supertype practiced a high level of discipline. In other words, subtyping "just works" for clients in OO languages. It takes (IMO) unacceptable levels of discipline in XML Schema.
|
