libxmlplusplus-general — Open discusions about libXML++

Re: [Libxmlplusplus-general] Parser abstraction

[Stefan S. <se...@sy...>]

Christophe de Vienne wrote:

>>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(...) the 
> parse method returned something.
> For me the parse methods tells the parser to do the actual parsing, after what 
> we eventually go to get the result. Returning the Document would be the 
> semantic of a createDocument method, which could cohexist with parse.
> The two parsers, even if working very differently, has a common point : they 
> parse something. I find logical to put the functions for that action in a 
> common interface.

hmm, from my point of view 'parsing something' is the 'how', while
'creating a document' is the 'what'. In other words, in the DOM way of life
I create a document from file/memory and the fact that something is parsed
is an implementation detail. The SAX model then renders that detail explicit,
i.e. in the world of SAX the fact that something is parsed is the actual semantics.

That's precisely why it is natural to implement a DOM document creation on SAX.

In short, SAX and DOM don't operate on the same level, they both describe two
very different worlds.

> Is it really unbearable to write each time :
> DomParser p;
> p.parse(something);
> Document * doc = p.getDocument();
> 
> especially if we introduce the create_document_from_file(...) function ?

well, it's of course not unbearable, but it's unintuitive and inelegant.
Again, I'm excluding stateful (chunk-wise) parsing here.
If parsing is an atomic action, why should I need two methods to get
a document from a file ?

> The situation I was thinking of would be to create a class that is able to 
> read a document from a special source, for exemple network with a weird 
> protocol, and to which we could give the Parser which has to parse it.

well, for 'special sources' there is the 'std::streambuf' abstraction in
C++. Us that when you want to abstract away the physical nature of the source
you are reading from.

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

We gain clarity and elegance. (did you ever get to appreciate the elegance
of simple mathematical formulae ? If so, you'll surely understand what I mean).

> I'd like to have some more points of view since we'll have to make a decision 
> at last.

heh, you are right. Let's listen to the others :-)

Stefan

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

Re: [Libxmlplusplus-general] coding style issues

[Stefan S. <se...@sy...>]

Jonathan Wakely wrote:

> GCC 2.95 doesn't support using declarations at class scope if the name
> is subsequently overloaded, so hidden functions must be redefined.
> RedHat's GCC 2.96 does support such using decls, but FreeBSD's 2.95.4
> doesn't, and AFAIK Debian's 2.95.4 doesn't either.
> Should libxml++ work with GCC 2.95 ?

I'm puzzled, I just tried to compile this chunk with a home-built 2.95.3:

----
class A
{
protected:
   void foobar();
};

class B : public A
{
public:
   using A::foobar;
};
----

with 'gcc version 2.95.3 20010315 (release)'

and it worked fine.

Stefan

Re: [Libxmlplusplus-general] Parser abstraction

[Stefan S. <se...@sy...>]

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 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.

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 ?

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

> 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 ?

Stefan

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

Re: [Libxmlplusplus-general] Parser abstraction

[Jonathan W. <co...@co...>]

On Sat, Feb 01, 2003 at 03:27:20PM -0500, Stefan Seefeld wrote:

> Christophe de Vienne wrote:
> 
> >The way parse_stream or an eventual parse_chunk is implemented could be 
> >shared, since only the parser state is initialised differently (and 
> >partialy only, since some options are the same ones).
> >Even the parse_file and parse_memory could share the same implementation 
> >in both classes if we used more low level libxml calls.
> 
> ok. Well, right now they don't share *any* code. And even if they would use
> those common function(s), it would be a single line (or two). So code reuse
> can't be an issue here.

In any case, public inheritance shouldn't be used for code reuse.

> >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.

Yes. The C library has no access control, but the C++ wrapper should use
protected or private inheritance in order to share implementations.

jon

-- 

Re: [Libxmlplusplus-general] Parser abstraction

[Stefan S. <se...@sy...>]

Christophe de Vienne wrote:

> The way parse_stream or an eventual parse_chunk is implemented could be 
> shared, since only the parser state is initialised differently (and partialy 
> only, since some options are the same ones).
> Even the parse_file and parse_memory could share the same implementation in 
> both classes if we used more low level libxml calls.

ok. Well, right now they don't share *any* code. And even if they would use
those common function(s), it would be a single line (or two). So code reuse
can't be an issue here.

My main concern really is the semantic difference between DOM and SAX.
My point really is that you decide once whether you want to use an event driven
approach, or whether you want a full in-memory representation which you can
walk through and manipulate.
There isn't anything those two things have in common. Yes, document construction
can (and is in libxml2) be implemented on top of a SAX interface, but that's
an 'implementation detail'.

> Imagine I have several documents to parse with the same options. I could 
> instanciate a single parser instance that would become a factory of Document, 
> parameterized once for all, and without having to give theses options each 
> time to a factory function (which would mean store them somewhere).

ok, I can see that (though I'm not sure that there is anything favoring
to use the same options for all documents). I do think that in 90% of all
cases creation of a document is an atomic action, at least as far as the user's
code is concerned. 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 :-)

> 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.

> 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.

Regards,
		Stefan

Re: [Libxmlplusplus-general] Parser abstraction

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

Le Samedi 1 F=E9vrier 2003 20:34, Stefan Seefeld a =E9crit :
> Yet I maintain that there is nothing justifying a common base class for
> SAX parsers and parsers that create a DOM document. There isn't any code
> both would share, and there isn't any semantic commonality that could
> possibly make someone want to use an abstract parser reference, not knowi=
ng
> whether a call to 'parse' would mean 'generate a document' or 'call back =
on
> event X'.

The way parse_stream or an eventual parse_chunk is implemented could be=20
shared, since only the parser state is initialised differently (and partial=
y=20
only, since some options are the same ones).
Even the parse_file and parse_memory could share the same implementation in=
=20
both classes if we used more low level libxml calls.

>
> And I don't see the relevance of wanting to parse two things at the same
> time. What do you mean with 'at the same time' ? In different threads ?
> Chunks belonging to different documents ? If it's the second, I agree that
> we need a parser class (see above).

I was thinking of both cases, but more specialy of the second one.

> But if you aren't parsing in chunks,
> there isn't any state to remember that couldn't be passed to the actual
> 'parse' call (such as whether or not to preserve white space etc.)
>

Imagine I have several documents to parse with the same options. I could=20
instanciate a single parser instance that would become a factory of Documen=
t,=20
parameterized once for all, and without having to give theses options each=
=20
time to a factory function (which would mean store them somewhere).
Moreover, considering the underlying C layer, we could have not implemented=
=20
any accessor to use a particular option. Having the parser state initialias=
ed=20
by the parser instance and accessors before doing the real parsing would le=
t=20
the possibility to alter it through a cobj() accessor in a herited class

> In a nutshell, yes, I agree that in case of chunks a dom parser would be
> a solution. But even then there isn't anything this parser has in common
> with the sax parser.
>

The inputs are in common. In libxml for exemple, the xmlParseChunk is the s=
ame=20
for a sax or a dom parser : a Document will be produced if I don't specify =
a=20
saxHandler. Still in libxml, the domparser is built on top of saxparser : t=
he=20
two concepts share more things that it seems at first sight.
Having an abstract Parser class will, in my opinion, reflects better the=20
underlying lib.

Regards,

Christophe.

Re: [Libxmlplusplus-general] Parser abstraction

[Stefan S. <se...@sy...>]

Christophe de Vienne wrote:

> There is one case, which we did not implement yet although, that justify 
> having a state : libxml propose an interface, xmlParseChunk, that allow to 
> parse a document by small pieces. With a Parser class it will be easy and 
> natural to have, for exemple, two parsers building two document at the same 
> time without interfering. Even if it's a rare case, there is not much to do 
> to make it possible with a parser object, while having a function would force 
> us to add a state.

I don't understand that statement. Yes, I agree, if we ever want to parse
a document chunk-wise, we need a stateful parser that can remember where it
left of. I fully agree that for this case we want a parser class.

Yet I maintain that there is nothing justifying a common base class for
SAX parsers and parsers that create a DOM document. There isn't any code
both would share, and there isn't any semantic commonality that could possibly
make someone want to use an abstract parser reference, not knowing whether
a call to 'parse' would mean 'generate a document' or 'call back on event X'.

And I don't see the relevance of wanting to parse two things at the same
time. What do you mean with 'at the same time' ? In different threads ?
Chunks belonging to different documents ? If it's the second, I agree that
we need a parser class (see above). But if you aren't parsing in chunks,
there isn't any state to remember that couldn't be passed to the actual 'parse'
call (such as whether or not to preserve white space etc.)

In a nutshell, yes, I agree that in case of chunks a dom parser would be
a solution. But even then there isn't anything this parser has in common
with the sax parser.

Regards,
		Stefan

Re: [Libxmlplusplus-general] coding style issues

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

Le Samedi 1 F=E9vrier 2003 19:15, Jonathan Wakely a =E9crit :
> Should libxml++ work with GCC 2.95 ?

Since it's still probably more widely used than gcc 3.x, yes.

Christophe

Re: [Libxmlplusplus-general] coding style issues

[Jonathan W. <co...@co...>]

On Fri, Jan 31, 2003 at 11:13:34AM -0500, Stefan Seefeld wrote:

> 1) I suggest to use 'using namespace xmlpp;' inside .cc files,

IMHO this is a Good Thing.

> 2) 'using foomethod;' in derived class declaration:
>    Murray suggests people may not be familiar with that concept.
>    The goal of this shortcut is to drag base class methods into the
>    derived class. A more lengthy way would be to write
>    'foomethod() { BaseClass::foomethod();}
>
>    That's relevant in two situations:
>    a) the base method declares the method in question as being
>       protected, while the derived class wants to expose it publicly.
>    b) the derived class overrides the method by a method with the same
>       name, but a different signature. Example:

(N.B. this is an overload, not an override)

>       the base class has 'void foo();', and the derived class defines
>       'void foo(int);'. This would hide the original 'void foo();'
>       method, so if you want to expose both, you have to redeclare (via
>       'using') or redefine it.

FYI:
GCC 2.95 doesn't support using declarations at class scope if the name
is subsequently overloaded, so hidden functions must be redefined.
RedHat's GCC 2.96 does support such using decls, but FreeBSD's 2.95.4
doesn't, and AFAIK Debian's 2.95.4 doesn't either.
Should libxml++ work with GCC 2.95 ?

jon


-- 
"Always Read the Label"
	- anon.

Re: [Libxmlplusplus-general] Parser abstraction

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

Le Samedi 1 F=E9vrier 2003 16:42, Stefan Seefeld a =E9crit :
> Christophe de Vienne wrote:
> > Moreover, I personnaly think that having a DomParser class makes more
> > natural the fact to have several parser working at the same time.
>
> I don't understand that. Again, generating a document object doesn't
> involve any state that justifies a parser *object*. Even the parser optio=
ns
> you are talking about could well be put into the 'create_document' functi=
on
> arguments (with sensible default values).
>

There is one case, which we did not implement yet although, that justify=20
having a state : libxml propose an interface, xmlParseChunk, that allow to=
=20
parse a document by small pieces. With a Parser class it will be easy and=20
natural to have, for exemple, two parsers building two document at the same=
=20
time without interfering. Even if it's a rare case, there is not much to do=
=20
to make it possible with a parser object, while having a function would for=
ce=20
us to add a state.

Regards,

Christophe

Re: [Libxmlplusplus-general] NodeLists, AttributeLists, etc.

[Stefan S. <se...@sy...>]

Christophe de Vienne wrote:

> I agree that the Attribute class is no longer switable for this purpose.
> As far as the pair of string, we should keep consistency between this and the 
> way we do for Nodes contents : use templates... and this is true for the 
> other methods too, although I'm not sure it will make things clear/easy (but 
> this may be because it's a bit late for me :-/

yes, I totally agree. We ought to use a consistent approach to represent
character types, and use that throughout the API.

Regards,
		Stefan

Re: [Libxmlplusplus-general] Parser abstraction

[Stefan S. <se...@sy...>]

Christophe de Vienne wrote:

> The main interest I see in keeping an abstraction for parser is that they have 
> common options. One thing I want to be done on it is to be able to configure 
> the parsers through this abstact Parser class. The options I'm refering to 
> concerns, for exemple, if the document has to be validated or not. I don't 
> have in mind the complete list of them but they're is other ones that are 
> interesting to have.
> The difference between both parsers is the output, but the input is exactly 
> the same : we can parse a file, a buffer, a stream, and the abstraction 
> defines only how input can be given to the Parser, not the way to retrieve 
> any result.

ok, I see. Well, this option-setting mechanism isn't currently part of the
API. Would it be, I probably wouldn't ask the question.


> I don't think having a Document class is incompatible with a parser 
> abstraction. Your factory function is in fact a DomParser, which returns a 
> Document instead of a root_node (this probably better, since it's closer to 
> libxml).

indeed.

> Moreover, I personnaly think that having a DomParser class makes more natural 
> the fact to have several parser working at the same time.

I don't understand that. Again, generating a document object doesn't involve
any state that justifies a parser *object*. Even the parser options you are
talking about could well be put into the 'create_document' function arguments
(with sensible default values).

Stefan

Re: [Libxmlplusplus-general] NodeLists, AttributeLists, etc.

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

Le Vendredi 31 Janvier 2003 20:12, Stefan Seefeld a =E9crit :
> I'v the impression that Node/Attribute containers
> could/should be avoided, at least in the DOM programming
> model: Once you get hold of a node, you may iterate over
> the child nodes by means of an iterator, avoiding unnecessary
> copies (of pointers, but still...)

That make sense to me.

>
> The only context in which I can see the need for a 'NodeList'
> is when you search for matching nodes in a document (using
> xpath expressions, say), so the result will be a temporary
> list.

Agree.

>
> The SaxParser uses an 'AttributeMap', containing Attribute pointers.
> Given that an 'Attribute' is now a wrapper around a node (which is
> by design associated with the DOM programming model), I suggest
> we replace that with a simple pair of (unicode) strings. The
> current implementation will leak, as there is no way to delete
> attributes outside a document (again, by design, because Attributes
> live in the context of a document, which doesn't exist with SAX).
>

I agree that the Attribute class is no longer switable for this purpose.
As far as the pair of string, we should keep consistency between this and t=
he=20
way we do for Nodes contents : use templates... and this is true for the=20
other methods too, although I'm not sure it will make things clear/easy (bu=
t=20
this may be because it's a bit late for me :-/

> Suggestions ?

Well, nothing concrete for now, I'll think again about it tomorrow...


Best regards,

Christophe

Re: [Libxmlplusplus-general] Parser abstraction

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

Le Vendredi 31 Janvier 2003 20:06, Stefan Seefeld a =E9crit :
> hi there,

hi

>
> libxml++ currently defines an abstract 'Parser' interface,
> which is implemented once to provide a DOM parser, and once
> for SAX.
>
> I'm wondering how useful such ab abstraction is. The implementation
> is completely different, and even for users there isn't anything
> the two have in common, i.e. the semantics of 'parse file "foo"' is
> very different.
>

The main interest I see in keeping an abstraction for parser is that they h=
ave=20
common options. One thing I want to be done on it is to be able to configur=
e=20
the parsers through this abstact Parser class. The options I'm refering to=
=20
concerns, for exemple, if the document has to be validated or not. I don't=
=20
have in mind the complete list of them but they're is other ones that are=20
interesting to have.
The difference between both parsers is the output, but the input is exactly=
=20
the same : we can parse a file, a buffer, a stream, and the abstraction=20
defines only how input can be given to the Parser, not the way to retrieve=
=20
any result.

> I'v (locally) introduced a 'Document' class, which is created
> by a 'create_document_from[file, stream, memory]' factory function.
> Note that this is really a function, as there isn't any state involved.
> Either you end up with a document, or you don't (an exception may be
> thrown to indicate failure).

I don't think having a Document class is incompatible with a parser=20
abstraction. Your factory function is in fact a DomParser, which returns a=
=20
Document instead of a root_node (this probably better, since it's closer to=
=20
libxml).
Moreover, I personnaly think that having a DomParser class makes more natur=
al=20
the fact to have several parser working at the same time.
One other argument I would have is that it is, in my opinion, closer to=20
libxml.

>
> What do you think about such a change ? Do we still need an abstract
> Parser class ?
>

I vote pro ;-)
Unless you prove me I'm wrong of course...

Cheers,

Christophe

[Libxmlplusplus-general] NodeLists, AttributeLists, etc.

[Stefan S. <ste...@or...>]

I'v the impression that Node/Attribute containers
could/should be avoided, at least in the DOM programming
model: Once you get hold of a node, you may iterate over
the child nodes by means of an iterator, avoiding unnecessary
copies (of pointers, but still...)

The only context in which I can see the need for a 'NodeList'
is when you search for matching nodes in a document (using
xpath expressions, say), so the result will be a temporary
list.

The SaxParser uses an 'AttributeMap', containing Attribute pointers.
Given that an 'Attribute' is now a wrapper around a node (which is
by design associated with the DOM programming model), I suggest
we replace that with a simple pair of (unicode) strings. The
current implementation will leak, as there is no way to delete
attributes outside a document (again, by design, because Attributes
live in the context of a document, which doesn't exist with SAX).

Suggestions ?

Stefan

[Libxmlplusplus-general] Parser abstraction

[Stefan S. <ste...@or...>]

hi there,

libxml++ currently defines an abstract 'Parser' interface,
which is implemented once to provide a DOM parser, and once
for SAX.

I'm wondering how useful such ab abstraction is. The implementation
is completely different, and even for users there isn't anything
the two have in common, i.e. the semantics of 'parse file "foo"' is
very different.

I'v (locally) introduced a 'Document' class, which is created
by a 'create_document_from[file, stream, memory]' factory function.
Note that this is really a function, as there isn't any state involved.
Either you end up with a document, or you don't (an exception may be
thrown to indicate failure).

What do you think about such a change ? Do we still need an abstract
Parser class ?

Regards,
		Stefan

Re: [Libxmlplusplus-general] coding style issues

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Vendredi 31 Janvier 2003 17:57, Stefan Seefeld a =E9crit :
> Besides, as I noted in the patch manager thread, I can see a future
> change in libxml++ where we only have a single 'Node' base class
> providing complete access to the full libxml2 node API, but in terms of
> 'xmlChar *', not 'std::string', and then make the concrete node types
> templates. Thus it's really a matter to keep the code simple to
> concentrate it in xmlpp::Node...

I like this idea.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj46r48ACgkQB+sU3TyOQjAIdwCdHiwJpxK9uftq66L5m6AWy9p3
C/UAoJRASRX4/zFf+0sN9k2DVGc15eib
=3DEM9D
=2D----END PGP SIGNATURE-----

Re: [Libxmlplusplus-general] coding style issues

[<mu...@t-...>]

On Fri, 2003-01-31 at 17:13, Stefan Seefeld wrote:
> 3) hiding state in the private section:
>     It's a matter of good encapsulation to put all members into the
>     private section, and then provide accessors (either public or
>     protected). That helps to decouple dependencies between base and
>     derived classes. Of course, derived classes then can't access the
>     member variable. That's exactly the point, that's the goal !

And I say "you can't predict the future" so you should not completely hide complex types.

For instance, in gtkmm, every class has a gobj() accessor so people can get at the underlying C 
instance if we haven't wrapped something. This will be the same in libxml++ - if people need to
use a libxml function that isn't wrapped in libxml++ then they will need access to the pointer to
the underlying C struct. I intend to add cobj() accessors if we apply your patch. 

[Libxmlplusplus-general] coding style issues

[Stefan S. <ste...@or...>]

hi there,

Murray asked me to drag some points we were discussing on the patch
manager into this list...

We were discussing some code styling issues, and I'd like to raise
these points again here:

1) I suggest to use 'using namespace xmlpp;' inside .cc files,
    as that is more restrictive. It means that the compiler will not
    put any additional symbols *declared* in the .cc file into the
    xmlpp namespace, but only associate *definitions* with declarations
    from the headers.
    I prefer that because it's more explicit. (Specifically, when you
    explicitely want to hide symbols, put them into anonymous namespaces)

2) 'using foomethod;' in derived class declaration:
    Murray suggests people may not be familiar with that concept.
    The goal of this shortcut is to drag base class methods into the
    derived class. A more lengthy way would be to write
    'foomethod() { BaseClass::foomethod();}

    That's relevant in two situations:
    a) the base method declares the method in question as being
       protected, while the derived class wants to expose it publicly.
    b) the derived class overrides the method by a method with the same
       name, but a different signature. Example:
       the base class has 'void foo();', and the derived class defines
       'void foo(int);'. This would hide the original 'void foo();'
       method, so if you want to expose both, you have to redeclare (via
       'using') or redefine it.

3) hiding state in the private section:
    It's a matter of good encapsulation to put all members into the
    private section, and then provide accessors (either public or
    protected). That helps to decouple dependencies between base and
    derived classes. Of course, derived classes then can't access the
    member variable. That's exactly the point, that's the goal !

Comments and criticism are appreciated...

Stefan

Re: [Libxmlplusplus-general] libxml++ evolution

[Stefan S. <se...@sy...>]

Murray Cumming wrote:
> On Thu, 2003-01-30 at 17:47, Stefan Seefeld wrote:
> 
>>However, I don't agree that individual checkins must not generate
>>regressions. Sometimes changes are quite complex, and imply more than
>>just an implementation fix.
> 
> 
> Rejecting regressions is a reliable way to ensure that the code doesn't
> stay broken. Half-finished changes have significantly delayed or killed
> projects in the past. It's OK if you are going to fix-and-simultaneously
> improve things with your next check-in in a few minutes. 

I fully agree. Chances that subsequent commits will fix the regression
are higher if the person who commits is a core member, i.e. it's somehow
a question of trust.

> But taking the current patch as an example, if we don't check that it
> works then we _might_ discover later that we've made a fundamental
> change which can _never_ support even the old functionality. And, after
> all, the other patches that you've suggested are additions to the API,
> so it won't be any waste of time to make sure that the existing API
> still works with the patch.

well, as I said, there are parts of the API that are fundamentally 
incompatible with the suggested change: It's more than a change in 
implementation if the new code is *strictly* a wrapper around libxml2,
i.e. doesn't implement itself a DOM tree, but *always* delegates down.

So strictly speaking, a change like that may be required to be justified
by a design document. Though that's getting quite a bit formal, and it
would be the first time in an open project that I see that degree of
formal development process. (well, actually, I'm trying to encourage
developers in the fresco project to do just that, as things tend to
get out of hands at times...:-) But compared to that project, libxml++
is really small...)

> However, it's not too bad to submit incomplete candidate patches and
> gradually revise those patches until one is fit for a commit.

agreed, especially if part of the exercise is to get familiar with
internal project policies, for example coding guides etc.

Stefan

Re: [Libxmlplusplus-general] libxml++ evolution

[<mu...@t-...>]

On Thu, 2003-01-30 at 17:47, Stefan Seefeld wrote:
> However, I don't agree that individual checkins must not generate
> regressions. Sometimes changes are quite complex, and imply more than
> just an implementation fix.

Rejecting regressions is a reliable way to ensure that the code doesn't
stay broken. Half-finished changes have significantly delayed or killed
projects in the past. It's OK if you are going to fix-and-simultaneously
improve things with your next check-in in a few minutes. 

But taking the current patch as an example, if we don't check that it
works then we _might_ discover later that we've made a fundamental
change which can _never_ support even the old functionality. And, after
all, the other patches that you've suggested are additions to the API,
so it won't be any waste of time to make sure that the existing API
still works with the patch.

However, it's not too bad to submit incomplete candidate patches and
gradually revise those patches until one is fit for a commit.
  
> I think it's much more easy to make
> the transition incrementally, accepting that the code will temporarily
> contain regressions, as long as they are well known and tracked.

Incremental development is great, and I will always demand it. But that
doesn't require regressions in most situations.

-- 
Murray Cumming
mu...@us...
www.murrayc.com

Re: [Libxmlplusplus-general] bugs?

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

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Could you provide us a patch through the patch manager ?

Thanks very much

Christophe

Le Vendredi 31 Janvier 2003 14:08, Philipp Krause a =E9crit :
> domparser.cc, line 71: getline should be changed to std::getline
> saxparser.cc, line 170: getline should be changed to std::getline
> domparser.cc, line 129: remove semicolon at end of line
> element.cc: In function write there are to variables both named iter,
> since they are declared in the for statement this is OK with the current
> C++ standard, but some compilers (like MSVC++) still follow the older
> version. Please rename them to unique names.
>
> Philipp Krause
>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj46drgACgkQB+sU3TyOQjDERACfRcVhVqZDUXD+Q6PCrUwhfUrC
Mg0AnRrHUBnfRrOTfUOLbAhqZz1tkW4R
=3D30Ly
=2D----END PGP SIGNATURE-----

[Libxmlplusplus-general] bugs?

[Philipp K. <pk...@sp...>]

domparser.cc, line 71: getline should be changed to std::getline
saxparser.cc, line 170: getline should be changed to std::getline
domparser.cc, line 129: remove semicolon at end of line
element.cc: In function write there are to variables both named iter,
since they are declared in the for statement this is OK with the current C++
standard, but some compilers (like MSVC++) still follow the older version.
Please rename them to unique names.

Philipp Krause