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

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

"Thorsten Ottosen" <thorsten.ottosen_at_[hidden]> wrote in message 
news:444B3FDD.3000404_at_dezide.com...
: Ivan Vecerina wrote:
: > I would plainly take out all the member functions labeled as
: > "Ptree-specific operations" (see basic_ptree in the Synopsis in the
: > main doc page: http://kaalus.atspace.com/ptree/doc/index.html ).
: > A first step would be to convert them into a set of non-member
: > functions (preferably in a separate header file).
:
: Why do you think it is an advantage to make these functions non-members?
: They still mention the property_tree in the parameter list and so are
: logically still is part of the public interface of ptree.
: (Thus the claim about lower coupling is somewhat overstated for a
: library that rarely changes).

Well, I think that I am of a school of thought defended by Scott Meyers,
Herb Sutter, Andrei Alexandrescu, and others:
 http://www.ddj.com/dept/cpp/184401197
 http://www.gotw.ca/publications/mill02.htm

: IFACIT, (especially normal) users prefer members. It gives them one
: place to look for the interface (and is really handy in most IDE's when
: "." triggers a list of functions). Or we could go back to C and make
: everything a non-member.

Very concretely, here, the issue is that we heading for an std::string
syndrome.  Take a look at c.l.c++ and see how often users want to
derive from std::string to extend its interface.
std::string includes about a hundred of member functions (many of
which overlap with operations available in std::algorithm). Yet it
will never be enough: users look for trimming functions, case or
encoding conversion functions, etc etc.

Do you think that std::string is an example that ptree wants to follow?

Marcin already has included a large set of useful operations as members:
there are already 27 functions under "Ptree-specific operations",
and Marcin has already identified members that he would like
to add (e.g. 'set' as a complement to 'put').
Yet they will never satisfy a large enough user base. Some want path
access with separate strings. Some want path access with '.', or '/',
or any char as a separator. Some want to escape the separator. Some
ask for array indexing - embedded in the string, or as a separate
operation.  And many users may never want to use paths !
Then there is improved support for arrays (why do I have to push_back
a pair when I only should specify 'second', the array value ?),
error handling policies (what happens if a path is ambiguous
because multiple children are homonyms?), and more.
How many member functions do we want to have in the end ?
Will those be representative of the interface subset that
a majority of users wants to use?

Too many members are confusing too: we had a couple posts already
from people who were expecting ptree::find to accept paths.

I also haven't found a description of how to customize the
conversion of some UDTs to ptree. This should be possible,
and IMO is done more naturally with non-member templates.

No matter how hard you try, you will end up having a mess of a
large member-interface, yet fail to satisfy the needs of the
majority.

The only adequate solution I see to this problem is to provide
a minimum set of member functions.  Then document well a core
set of primitive operations (non-members in my preference).
And if we want to provide a "simple interface for dummies",
put it in a sub-namespace ( ptree::path ) so those who want
to use your default simple interface can include it & find
it there.

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