Re: [boost] [Boost Review] Property Tree Library

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-25 17:44:46

Hi Pavel,

Thank you for another review, it's probably 4th or even 5th, counting ones 
you did before the review started.

> Temptation to extend the now simple API into
> giant does-it-all tool may result in something
> practically no one would dare to use.

Right. A lot of the people posting to this thread proposed at least one new 
major feature. If I added all of them (if I ever managed to), the library 
would sink under its own weight.

> 1. Examples, examples, examples.

Probably a very good idea. But I need to port docs to QuickBook first. 
Otherwise maintaining it is going to kill me.

>    Rename the library to "simple property tree"
>    if people cannot stop requesting more.

He he he. I don't think it is going to stop them.

> * basic_string should not be hardcoded.
>  There are too many string implementations floating
>  around.

It is now only "soft-coded" for the key type. By "soft-coded" I mean that 
some std::string interface is required (substr etc.), but key_type itself 
can be changed. Of course, this sort of partial solution is not sufficient. 
Adding more generic path/keys support is the now the most important change 
waiting in the queue.

> * Optional MT safety may be added.

I would rather leave it at std::container style - no built-in safety.

> * Preserving comments and whitespace in INI/JSON/INFO
>   could be the /most/ important reason someone
>   decides to use the library.

The more I think about it, the simpler it seems, and originally I thought it 
is a definite no-no, just look at my replies to Jeff Garland. Some suggested 
adding extra fields to the node, but this is not acceptable for me; if 
comments cannot be handled by the tree alone it's better if they are not 
handled at all. The way to do it is to add metadata (like <xmlattr> or 
"\values"), which describes comments and optionally location. Of course this 
will slow some of the parsers very significantly, so it should be optional. 
Metadata will be fully editable, but will not pollute normal data. I hope 
this is doable.

> * The property tree itself may be serializable
>  as it could be part of larger application state

Yes. This is probably very easy to do.

> * Support for various Unicode encodings
>  (frex reading UTF16 BE and
>   converting the strings to ANSI, all transparently).

If I understand the problem correctly, this is a job for codecvt facet, it 
was designed to do it. Library only allows setting locale for all relevant 
operations.

> * Overloads for parsers to parse given memory block
>  (e.g. mapped file, shared memory)

Maybe. But how about doing another library that presents arbitrary memory 
block in form of C++ stream? I think it would be usable in many other 
contexts as well, and in one of my projects definitely. Stringstream is 
flawed because it must copy the data first. Copying whole memory-mapped file 
is really a rubbish idea :-)

> * An user defined datatype (e.g. boost::any) attached
>  to each node may be useful [...]

No problem now. Customize data_type.

Thank you again,
Marcin