On Monday, 10/06/2003 at 10:03 MST, Andy Clark <[EMAIL PROTECTED]> wrote:
> To clarify, I meant to say that I prefer the event
> *object* approach. This means that the information
> items are encapsulated within discrete objects
> instead of requiring the application to call a set
> of methods based on the item type.
Problem with that is that if these objects aren't singletons you're buying
a certain amount of heap churn -- and if they are singletons, the advantage
of callback through an event object versus callback through accessors on
the cursor itself appears to be negligable-to-absent. (I wrestled with this
as part of some experiments we're doing in other kinds of XML processing,
and came to the conclusion that putting a Node interface on the
Cursor/Iterator object itself was at least as clean as having Cursors
deliver Nodes.
Either way, you definitely want to let implementations avoid requiring the
creation of Objects to hold values until the API calls for those values.
SAX's habit of delivering a char{} reference requires it to always create
that array, which may be a nuisance if the source data isn't in that form
(eg, if you're serializing from an existing data structure which stored the
value as String, or as a numeric field). If the application recieving the
serial stream doesn't actually use that particular block of text, this
represents wasted computation and possibly wasted heap activity. Callbacks,
by allowing just-in-time data conversion, dodge that issue.
I still remain convinced that push vs. pull is something of a mis-statement
of the problem, which is that (a) module developers want to pull from their
input and push to their output, to simplify/optimize their own code, but
(b) application developers want to plug modules together efficiently, and
impedence-matching of a push output back into a pull input is NOT efficient
in most cases. I suspect that the real answer would be high-efficiency
coroutines. Unfortunately, doing that right requires support at the
programming language level, and Java doesn't offer it; the closest you can
come is to homebrew something around thread-switching, which is
heavier-weight than this task calls for.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
