[jdom-interest] Re: Fw: Suggestion for JDOM

[Richard Baldwin]

I'm going to expand on this suggestion and say that
every object that is stored in the List whose reference
is returned from the getMixedContent() method should be
instantiated from a class that implements a common
interface.  

That common interface should declare the set of methods
that are common to all such objects.  (Of course, any
of the objects could contain methods that are peculiar
to that object, which are not declared in the
interface.)

Then it would be possible to iterate on the list,
invoking any of the common methods polymorphically
without the requirement to determine the actual type of
the object using instanceof.  All that would be
necessary would be to cast each reference obtained from
the Iterator's next() method to the known interface
type before invoking any of the common methods.  

This would be in the spirit of the Java Collections
Framework, which is heavily based on the ability to
invoke methods polymorphically, and would be a very
familiar pattern for many Java programmers who are
accustomed to thinking in those terms.  

In fact, in keeping with the Framework's controversial
design, it would also be possible to declare methods in
the interface which are not supported by all of the
possible object types. If a method is not supported by
a particular type of object, it could throw an
exception.  However, I'm not suggesting that the
interface concept be pushed to this degree. I would be
satisfied with a common set of methods that is
supported by all of the possible object types.

Dick Baldwin

Brett McLaughlin wrote:
> 
> ----- Original Message -----
> From: "Richard Baldwin" <baldwin at austin.cc.tx.us>
> To: <brett.mclaughlin at javaworld.com>
> Sent: Monday, May 07, 2001 11:00 AM
> Subject: Suggestion for JDOM
> 
> > Hello Brett:
> >
> > Thanks for developing JDOM and making it available to
> > Java programmers.
> >
> > It seems to me that when I invoke getMixedContent() on
> > an Element, the resulting list should not contain a
> > reference to a String object for the text content of
> > the element.  Rather, it should contain a reference to
> > an object of some new class that encapsulates the
> > String, but also provides methods to implement other
> > capabilities such as those available with a Comment
> > object.
> >
> > For example, as it now stands, it is not possible to
> > invoke getParent() on the representation of the text
> > content of the element that is referred to by the item
> > in the list, because String doesn't recognize that
> > method.  This tends to break the pattern of the
> > programming interface for text content as compared to
> > Element, Comment, ProcessingInstruction, and Entity
> > objects.
> >
> > Encapsulating the text content of the element in such
> > an object would result in a more consistent programming
> > interface.
> >
> > Thanks
> > Dick Baldwin
> >
> > PS:  Keep publishing.  I find your articles and your
> > O'Reily book very informative.
> >
> > --
> > =========================================================
> > Richard G. Baldwin (Dick Baldwin)
> > Home of Baldwin's on-line Java Tutorials
> > http://www.geocities.com/Athens/7077/scoop/onjava.html
> >
> > Professor of Computer Studies
> > Austin Community College
> > (512) 223-4758 or (512) 250-8682
> > mailto:baldwin.richard at iname.com
> > http://www2.austin.cc.tx.us/baldwin/
> > ---------------------------------------------------------

-- 
=========================================================
Richard G. Baldwin (Dick Baldwin)
Home of Baldwin's on-line Java Tutorials
http://www.geocities.com/Athens/7077/scoop/onjava.html

Professor of Computer Studies
Austin Community College
(512) 223-4758 or (512) 250-8682
mailto:baldwin.richard at iname.com  
http://www2.austin.cc.tx.us/baldwin/
---------------------------------------------------------