[
Lists Home |
Date Index |
Thread Index
]
>-----Message d'origine-----
>De : Thomas B. Passin [mailto:tpassin@comcast.net]
>Envoyé : jeudi 7 mars 2002 02:41
>À : xml-dev@lists.xml.org
>Objet : Re: [xml-dev] Stupid Question (was RE: [xml-dev] XML doesn't
>dese rve its "X".)
>
( auto-quote sniped )
>
>{me]
>
>Well, think about extending an object. Any object that knows
>how to talk to
>the parent also knows how to talk to the child, but only with
>the methods of
>the parent. Of the new methods defined for the child, and its new
>properties, the older objects know nothing. This is much like
>ignoring new
>elements and attributes in markup when the schema has been
>changed, which
>you were arguing against, saying it would be a bad idea or
>unfeasible (I
>didn't quote that part).
Hello ? Do you know what polymorphism is ? Any object that knows how to talk
with the parent will know how to talk to the child, except that the
resulting behaviour is redefined in the child. The child can take its
extended state into account when replying to a method call from the parent
interface.
Look at Eric's example, where a schema changes so that what what previously
a simple #PCDATA now becomes a mixed #PCDATA + new tags. The parent object
had just a String getText() method. The child object can reimplement this
method to still return a String. What is returned depends on what is chosen
at implementation time : should we ignore the new elements, but keep their
text content ? Completely ignore the new elements and their content ? Throw
an exception to notify the caller that the getText() semantics cannot be
maintained with this new schema version ? Like Roy Lewis wrote in "How I Ate
My Father", "the possibilities are endless".
Plus, of course, the child object can add a new method which gives access to
the new data model, and this method will be used by callers that rely on the
new schema.
That's why I believe OOP can provide useful insights in bringing the X to
XML.
Regards,
Nicolas
|
