Re: [boost] [property_tree review] Making the interface leaner, concretely...

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-23 15:29:30

"Thorsten Ottosen" <thorsten.ottosen_at_[hidden]> wrote in message 
news:444B945C.3000509_at_dezide.com...
: I'm familiar with Scott's and Herb's views. However, just looking at
: Mayer's example
:
: struct Point {
:    int x, y;
: };
:
: vs
:
: class Point {
: public:
:    int getXValue() const;
:    int getYValue() const;
:    void setXValue(int newXValue);
:    void setYValue(int newYValue);
:
: private:
:   ...                 // whatever...
: };
:
: One of my brain-dead teachers back at universoty, showed the first as
: "the C way" and the second as "the superior Java way".
:
: It is certainly true that the latter is more encapsulted than the first.
: But it is also true that it is over encapsulated: there is no invariant
: to protect.
Exactly.
And property_tree without the value i/o encapsulates all
the relevant invariants.

: Here are some other examples of classes that has been designed
: as over-encapsulated:
:
: - std::complex
Agreed. It was probably pointless to hide the representation
as (real,imaginary) coordinates.

: - standard containers
In what way?

: > Do you think that std::string is an example that ptree wants to 
follow?
:
: No. But I don't see the analogy. A Sequence is a very common concept,
: but a property_tree is not. AFAICT, there's only going to be Marcin's
: tree.

The main interest of property_tree is that it provides a common gateway
to a variety of file-format back-ends.
In the same fashion, I think that we will have a variety of front-ends,
because needs vary, and an all-encompassing solution is not provided yet.

: If the free-standing functions are not generic, there is little point
: in not making them members. Having free-standing functions like
: get/set is a bad bad idea with the current rules for ADL.

I didn't explicitly indicate that the functions were templates,
but they obviously would be.

If we really want to provide member functions for ease-of-use
purposes, then I believe that we should make this a separate
class from the ptree "container".
It would be pretty straightforward to do so.

Ivan
-- 
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form