Re: [Libxmlplusplus-general] Parser abstraction

[Christophe de V. <cde...@al...>]

Le Samedi 1 F=E9vrier 2003 21:27, Stefan Seefeld a =E9crit :
> [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 =3D 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 t=
he
> > 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 in=
to
> 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 t=
he=20
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 produ=
ce,=20
their parse_xxx methods do have exactly the same semantic, so why not havin=
g=20
them in a common interface, even if in 99.00% of cases polymorphism will no=
t=20
be used.
Keeping it would permit, for exemple, to make an adaptator to be able to pa=
rse=20
from a new type of source which would be working for both parsers.

Cheers,

Christophe