Lists Home |
Date Index |
- From: James Clark <firstname.lastname@example.org>
- To: xml-dev Mailing List <email@example.com>
- Date: Wed, 17 Dec 1997 17:47:27 +0700
Don Park wrote:
> >I don't see the point of the XmlProcessor first argument. What's wrong
> >with having the implementation of XmlApplication store the XmlProcessor
> >in the member variable? (This is what SP typically does.)
> XmlApplication can not store the XmlProcessor in the member variable because
> it is an interface. I am very happy to see that XmlProcessor and
> XmlApplication are interfaces rather than classes.
I didn't suggest XmlApplication should should store XmlProcessor in a
member variable. I suggested that implementations of XmlApplication
could (if they needed to make callbacks to XmlProcessor) store
XmlProcessor in a member variable.
> >I don't think this is a good idea. It adds complexity and it's likely
> >to impose a performance cost, but it doesn't buy you anything, because
> >you can achieve that functionality with a MultipleXmlApplication class
> >that implements the XmlApplication interface, and provides
> >addApplication and removeApplication methods, and then forwards each
> >event to the applications that have been added to it.
> Support of multiple event listeners is the norm in the Java world. As they
> say "When in Texas, wear cowboy boots".
I don't think it's appropriate to carry over patterns from GUI events
and apply them to XML events just because we happen to use the word
"event" to describe them both. I believe performance is important for
XML processing, and an interface shouldn't impose an unnecessary
The real merit of this interface is that it's simple; unless there's a
really compelling need for a feature, I think it should be left out.
> If we were really concerned about performance, I
> would recommend giving up the use of String.
It's (rightly in my view) done that already for character data (which I
think is right). It's not a problem for element type names, because an
implementation can maintain a hash table of names and thus only allocate
a String for each distinct element type.
> >> userData property also gives users a chance to pass extra information
> >> to the processor easily, if they wish.
> >Surely there are cleaner ways to do this sort of thing.
> I do not think so. Just as every Mac developer loved having RefCon to hang
> thing onto, I like userData.
Could you explain a typical case where you need this?
Are there any standard Java classes that do this?
It feels very wrong to me; it's the sort of thing I would try hard to
avoid in my own programming, but maybe this is my strongly-typed C++
prejudices showing through. To me it seems like a feature that one can
easily manage without.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)