Re: [ubl-ndrsc] XML and Polymorphism

["Eve L. Maler" <eve.maler@sun.com>]

This writeup makes a ton of sense to me, and since I'm *not* a 
programmer, I'm willing to take what you say in this area pretty 
seriously!  And as long as the terms are defined, they should be safe 
anyway.

That said, it seems to me that the word "polymorphism" doesn't add a lot 
beyond plain "inheritance".  In the new context methodology paper, I 
think the two of them are mentioned in the same breath (as it were) and 
are not really referred to again.  But if you think invoking 
polymorphism will help the understanding of programmer-types, that's great.

	Eve

Matthew Gertner wrote:
> I'm not sure I am understanding this, perhaps because I am a programmer
> and not a document head. :-)
> 
> My understanding of OO principles is as follows:
> 
> - Inheritance
> This means what is says. One type gets ("inherits") some properties
> (data or behavior) from another type. I guess that this doesn't
> necessarily mean, in theory, that the inheriting type is a subtype of
> the original type, but in practice this is always the case is C++ and
> Java. In other words, the set of all instances of the new type is a
> subset of the set of all instances of the original type.
> 
> - Multiple inheritance
> In this case, the new type inherits properties from two or more types.
> This means that I can have an Animal type and a AnnoyingDrooling type
> and my Dog type becomes a subtype of both. (Just to reinforce my
> reputation as a latter-day W.C. Fields I should point out that Child
> would be derived from Human and AnnoyingDrooling.)=20
> 
> - Interfaces
> Multiple inhertiance turns out to be pretty problematic in practice,
> since there are sometimes conflicts between the data members and/or
> behavior of the two parent types. Therefore multiple inheritance is
> generally avoided, and in Java this is replaced with the concept of
> interfaces. In this case the new type inherits everything from the first
> parent and just the external interface of the second (and third, fourth,
> etc.) parent, which doesn't have any data members. Any behavior linked
> to this interface has to be reimplemented in the derived type.
> 
> I was going to extend my previous example to illustrate this point but
> the discussion got a little too gross for a public list. Let's just
> imagine I have an Engineer type and a Doctor type. Both have an
> attribute "Salary". So if want to create an EngineeringDoctor type that
> inherits from both, it won't know which "Salary" attribute to use. This
> can be a serious problem since both classes might have methods which use
> the "Salary" attribute to do internal computation.
> 
> The solution used in Java is to have, say, a Doctor class as above, and
> an Engineeringable interface that includes the additional methods that
> need to be supported if something is to behave as an engineer (e.g.
> "BabbleUnintelligibly"). These methods need to be implemented explicitly
> in the derived class, so if the depend on salary, for example, they can
> be programmed in the EngineeringDoctor class to use the "Salary"
> attribute of the doctor, as one should expect. This works very well and
> is often simulated in C++ by using "mixin" classes which are essentially
> the same thing as Java interfaces.
> 
> - Polymorphism
>>From the Greek roots "poly" (many) and "morph" (shape), this means "many
> shaped" (as you can see I am a startlingly original etymologist). In
> English: you can use any derived type when the base type is expected. So
> if my program expects a Doctor I can still use the EngineeringDoctor
> type there, since it inherits (and perhaps modifies) all the behavior of
> the base type, and if my program expects an Engineeringable interface
> then I can use the EngineeringDoctor type as well, since it implements
> this interface.
> 
> The XML analogy is that a processor should be able to use a derived type
> if it is found in a document where the processor was expecting the base
> type. I don't think that XML has any analogy for multiple inheritance or
> interfaces, a fact about which I think we should be very, very pleased.
> 
> Please let me know if any of this makes sense...
> 
> Cheers,
> Matt
-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com