Paul Sandoz wrote:
> To keep things consistent with "writing to" and "reading from" or
> "pushing" and "pulling" perhaps the following would be better:
>
> StreamReaderBufferProcessor readFromXMLStreamReader()
I'm not sure about this name, actually. If you just look at it, it
almost looks like the method is so that somehow you can fill an
XMLStreamBuffer from XMLStreamReader.
I really think "createXMLStreamReader", "newXMLStreamReader", or even
"getXMLStreamReader" would be better. I think these naming conventions
are well established.
> I have no problem with you making changes, but if you are time
> constrained will all the other the lots of other stuff you are doing i
> really do not mind doing this.
Thanks.
> The reason why XMLStreamBufferMark derives from XMLStreamBuffer is that
> i did not want any differentiation in terms of processing so that the
> user or the processors need not know when using a mark or not. But i
> agree it would be better to clear this up.
The changes you made looks good, but if I may add one more thing, we
should really keep a simple name for user-visible classes, and ugly
names for XMLStreamBuffer implementation.
So I think it's better to use the name "XMLStreamBufferMark" for the
current ImmutableXMLStreamBuffer, and then the current
XMLStreamBufferMark can be called like XMLStreamBufferMarkImpl or
something --- if Creator offers a method to create a new mark, the user
code wouldn't have to see XMLStreamBufferMarkImpl.
> The problem with making a mark an interface is that the processor needs
> to get access to the storage representation of the buffer but this
> should not be exposed to the user (because them the buffer can be
> modified in all sorts of nasty ways).
I think the way you made changes look just fine. I'm mostly concerned
about not having any public methods that the user applications can't
invoke, and I don't see any such methodin the current
ImmutableXMLStreamBuffer, so this is good.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com