Re: [Libxmlplusplus-general] Parser abstraction

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

Le Samedi 1 F=E9vrier 2003 23:13, Stefan Seefeld a =E9crit :
> Christophe de Vienne wrote:
> >>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 th=
ey
> > 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.
>
> the dom parser's 'parse' method(s) returns a document, the sax parser's
> 'parse' method returns nothing. How's this semantically the same, or
> equivalent ?
>

I did not realise that in your exemple of create_document_from_file(...) th=
e=20
parse method returned something.
=46or me the parse methods tells the parser to do the actual parsing, after=
 what=20
we eventually go to get the result. Returning the Document would be the=20
semantic of a createDocument method, which could cohexist with parse.
The two parsers, even if working very differently, has a common point : the=
y=20
parse something. I find logical to put the functions for that action in a=20
common interface.

> (ok, I'm excluding the case where you have to assemble the document from
> chunks here)

This means that parse_file should return a Document while when using=20
parse_chunk we would have to use an accessor to get it.
Is it really unbearable to write each time :
DomParser p;
p.parse(something);
Document * doc =3D p.getDocument();

especially if we introduce the create_document_from_file(...) function ?


>
> > 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.
>
> I don't understand that. You are still talking about code reuse, right ?
>

no. The remark Jonathan Wakely about public inheritance made me realize tha=
t=20
this is not the real interest of having a common interface.
The situation I was thinking of would be to create a class that is able to=
=20
read a document from a special source, for exemple network with a weird=20
protocol, and to which we could give the Parser which has to parse it.


My conclusion for now is that we would loose something (small but still) in=
=20
removing the common interface, while I don't see what we gain.

I'd like to have some more points of view since we'll have to make a decisi=
on=20
at last.


Best regards,

Christophe