OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: events vs callbacks (was Re: SAX2 (was Re: DOM vs. SAX??? Nah. ))

[ Lists Home | Date Index | Thread Index ]
  • From: Ken MacLeod <ken@bitsko.slc.ut.us>
  • To: "XML List" <xml-dev@ic.ac.uk>
  • Date: 26 Feb 1999 11:10:42 -0600

>>>>> "David" == David Megginson <david@megginson.com> writes:

    > Bill la Forge writes:
    >> >Event-based programming existed before people started
    >> >encapsulating events in structures or objects.  I'd define SAX
    >> as >an event-based API that reports events using callbacks.
    >> 
    >> But why are we not taking advantage of having the events as
    >> objects?  I've tried to second guess why this is so, but I
    >> think the arguments in favor of object-based events is
    >> stronger: the added overhead is balanced by greater simplicity
    >> and subsequently less overhead in other areas; the added
    >> flexability adding additional utility to all conformant code.

    David> From a design-pattern perspective, Bill is absolutely right:
    David> encapsulation and abstraction are big winners, and the way
    David> that he suggests is the proven method for building a robust
    David> system.

David goes on to say that using event objects will increase the size
of the implementation, increase the learning curve, and increase the
burden of documentation.  These statements seemed to be based on the
_unstated_ assumption that unique event classes will be used for every
type of event.

Why is it necessary to use unique event classes for each type of
event?  Why not use a NamedNodeList or simple dictionary type that can
hold the properties of the event?

If a simple dictionary type is used, then the implementation will
increase only by the size of one class (assuming a built-in class
isn't used), the documentation can be written in terms of the XML
Information Set (which XML application developers will need to be
familiar with anyway), and would still provide all the advantages Bill
la Forge is describing.

I used this design pattern in writing the Perl binding to SAX and,
although it hasn't been time-tested yet, the initial implementations
show a lot of promise and flexibility.

The draft for Perl SAX is available at:

<http://bitsko.slc.ut.us/~ken/perl-xml/libxml-0.01d7alpha.docs/SAX.html>

-- 
  Ken MacLeod
  ken@bitsko.slc.ut.us

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS