Andy Clark wrote: > Aleksander Slominski wrote: > > the interesting thing with immutable objects (such as element name > > represented as interned String) is that they can be kept indefinitely > > and shared very efficiently between parser and the user code > > > > however for other level objects such as start tag even the > > benefits, as you describe, are not that clear ... > > Well, we're talking about specific kinds of programs. Which > is why you've been working on xml-pull APIs and implementations. > In this work, have you found much need for the application to > keep parts of the docs around (e.g. the event contents) for > very long?
it depends: in case when i need to deserialize more complex data structure (such as SOAP graph) that parts of XML are not yet converted then one needs to keep event objects (as some kind of ultra lightweight partial DOM ...) > > the problem is to resist temptation of adding too much too fast, > > Yep, I agree. There would certainly be a tendency to add > everything but the kitchen sink. :) with public API: once something is added then it must be supported forever ... > > we think that in XMLPULL API we have some useful methods > > (like nextText/nextTag) and i personally think that more is needed > > but it is good to wait a bit and see what is _really_ needed. > > Yep. It's like when they erect a new building but don't > make the sidewalks -- they want to see where people walk > *before* laying the concrete. so we can depend on user to show us the way to go :-))) > > i think it is good for perfromance and will make code > > writing text gathering for element content much easier... > > I don't know about performance... I guess it really > depends on the application. otherwise one needs to use StringBuffer to keep content as it is not possible if there is one characters() callback or multiple for element content. if there was only one callback i still have to copy characters() buffer as it may be invalid when next endTag() callback is delivered ... thanks, alek --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
