[Property_tree review] Summary of enhancements proposed so far
I created a brief summary of enhancements/changes to property_tree which were proposed so far. 1. Make path a class in its own right and overload / (division) operator to concatenate path objects efficiently. This removes need for ugly default separator, and half of the get/put overloads. It also boosts performance (no more string operations on path), and IMHO will generally improve interface of the library. Most importantly, it largely does maintain compatibility with existing interface. 2. Split Traits into smaller policy classes. For example KeyPolicy and DataPolicy. Indeed, these two are mostly orthogonal, and it should be possible to replace one without touching the other. 3. Allow use of other data types as keys/paths (for example a vector of ints). Initial support is in the library, but key is still required to support string-like interface. 4. Add possibility to disable indexed lookup, if not required 5. Add possibility to specify names of "special" keys in parsers (<xmlattr>, <xmlcomment> etc.). Add whitespace-handling flags to XML reader. 6. Add "set" function. "set" will work in a similar fashion to put, except that it will always replace existing key if it exists. Extra boolean parameter to put functions will be gone. Alternative approach is to replace bool parameter to put with enum to improve readability. 7. Add "del" function. Del will erase existing keys from the tree, while presenting get/put/set style interface. This is clearly missing, although not immediately obvious. 8. Add support for array-style indexing in paths. This will probably work well with #1. 9. Add support for serialization of ptree objects 10. Add possibility to iterate over the whole tree in one go 11. Use multi_index internally for indexing 12. Make get/put functions freestanding 13. Add more docs on customizing key/data types. 14. Improve docs grammar/style in places. Break large index into smaller files. Additionally there were proposals to use runtime polymorphism to distinguish between leaf and branch nodes. I think this idea strays so far from current implementation/interface of the library, that it is not feasible to do. I hope this will serve as a basis for continued discussion. Best regards, Marcin
On 4/22/06, Marcin Kalicinski <kalita@poczta.onet.pl> wrote:
I created a brief summary of enhancements/changes to property_tree which were proposed so far. I hope this will serve as a basis for continued discussion.
Very nice to have all the proposal together. Maybe we can continue in this thread with ptree interface/implementation details. The principal thread is dominated by the pt/po/s11n discussion and is very dificult to track anything else.
5. Add possibility to specify names of "special" keys in parsers (<xmlattr>, <xmlcomment> etc.). Add whitespace-handling flags to XML reader.
Following this from the point of view of the ptree interface, i read a post that says it didnt like the "xxx.<xmlattr>.yyy" sintaxis. I think that whit the path class in place now we have the possibility to do, ( if we can make simple to create different path specialization ortogonal to the ptree ): xml_path p; data.put( p / "debug" / "info" + "attname" , 10 ); // Ovewrittes operator+ for attributtes, this will be equal to write: // p / "debug" / "info" / "<xmlattr>" / "attname" // The + selection has the advantage that it cannot be used in the middle // of the path construction expression, this make sence for attributes. data.put( p / "debug" / "info" / attr("attname") , 10 ); // Other approach... i like the first one more. The commentaries can be worked out to.
6. Add "set" function. "set" will work in a similar fashion to put, except that it will always replace existing key if it exists. Extra boolean parameter to put functions will be gone. Alternative approach is to replace bool parameter to put with enum to improve readability.
I like the set function more, much less to write and the same readability.
8. Add support for array-style indexing in paths. This will probably work well with #1.
Other thoughts in this point. I have realized that in many of the xml formats i used there are repetead tags to represent somenthing and the ordering is not important. an example <logFile> <log> .... </log> <log> .... </log> <log> <time> 10:02 </time> <text> error1 </text> <checked> false </checked> </log> <log> .... </log> <log> .... </log> </logFile> Sometimes it will be nice to modified the checked field of the log that have text error1. This can be done fairly simple with the actual interface of ptree, i think that in no more that a bunch of lines. But if this kind of task have to be repeated frequently will be nice to have an easy way to deal with it. For example if we permitted indexing in the paths, we can think that the path to the correct log is somewhat indexed by text subfield, so this to lines will produce the same result... data.set(p / "log"%where("text",bind(equal,_1,"error1")) / "checked" , "true" ); data.set(p / "log"%3 / "checked", "true" ); The where statement takes a "path", and a functor that have defined bool operator()(ptree::data &), this mechanism can be used for complex indexing. I feel it like a very nice to have feature that can be implemented too without affecting the actual easy to use interface.
Additionally there were proposals to use runtime polymorphism to distinguish between leaf and branch nodes. I think this idea strays so far from current implementation/interface of the library, that it is not feasible to do.
I'm agree with you.
participants (2)
-
Marcin Kalicinski -
Matias Capeletto