RE: [ubl-ndrsc] XML and Polymorphism

["Matthew Gertner" <matthew.gertner@acepoint.cz>]

You might be right. Maybe the best way to "explain" the polymorphism
concept is simply not to mention it...

Matt

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Monday, March 24, 2003 3:47 PM
> To: Matthew Gertner
> Cc: UBL NDR
> Subject: Re: [ubl-ndrsc] XML and Polymorphism
> 
> 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