Re: [Libxmlplusplus-general] Parser abstraction
- From: Christophe de Vienne <cdevienne alphacent com>
- To: libxmlplusplus-general lists sourceforge net
- Subject: Re: [Libxmlplusplus-general] Parser abstraction
- Date: Sat, 1 Feb 2003 22:00:01 +0100
Le Samedi 1 Février 2003 21:27, Stefan Seefeld a écrit :
> [snip]
> In that light I'd at least provide a factory
> function doing all this (possibly being implemented as
>
> Document *create_document_from_file(const std::string &filename, const
> options &o) {
> DomParser parser(o);
> Document *document = parser.parse(filename);
> return document;
> }
>
> so we are all happy :-)
youpi ;-)
>
> > Moreover, considering the underlying C layer, we could have not
> > implemented any accessor to use a particular option. Having the parser
> > state initialiased by the parser instance and accessors before doing the
> > real parsing would let the possibility to alter it through a cobj()
> > accessor in a herited class
>
> see my other mail: I don't think using 'cobj()' accessors should be
> encouraged. It totally breaks encapsulation.
encouraged not, possible in certain cases maybe.
> > The inputs are in common. In libxml for exemple, the xmlParseChunk is the
> > same for a sax or a dom parser : a Document will be produced if I don't
> > specify a saxHandler.
>
> right, and I think that is very unfortunate. It's two functions lumped into
> one; And its semantics is very different, depending on the arguments you
> pass.
>
> > Still in libxml, the domparser is built on top of saxparser : the
> > two concepts share more things that it seems at first sight.
>
> again, would you derive your dom parser privately from the sax parser,
> i.e. would you use 'derived from' in terms of 'implemented by', I would
> (possibly) agree.
>
Well, after rereading this long thread, I changed a little bit my mind on the
Parser abstraction, although I still have the feeling we should keep it.
If the two parsers doesn't have the same semantic as far as what they produce,
their parse_xxx methods do have exactly the same semantic, so why not having
them in a common interface, even if in 99.00% of cases polymorphism will not
be used.
Keeping it would permit, for exemple, to make an adaptator to be able to parse
from a new type of source which would be working for both parsers.
Cheers,
Christophe
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]