"Thorsten Ottosen" <thorsten.ottosen@dezide.com> wrote in message news:444B945C.3000509@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