Re: Tree-class for PEAR

> A common Tree class would IMHO be very welcome. I think we should ok, so i will commit it !? (is it allowed to put the *.php,v files in the cvs, directly, so all revisions stay available??) what name shall it have, is Tree/Tree.php and "Tree_Tree" as class name ok, or better: - class: Tree_Common, file: "Tree_Common.php" why i am asking is, this class implements a kind of tree class, which is extendable but implementing nested tree model in there would not really fit it's design, since it puts the tree in an array first and works on those array elements, upon every change it updates, the DB/XML-file but nested trees work more or less _only_ on the db, since it aims on huge trees > go for a different approach with your myPEAR_Common stuff though. definitely, that was only temporarily, so i could use it in a PEAR like structure on my machine :-) > Andrei is about to contribute a function called aggregate() which > basically does runtime interface import, which would be excellent > for this kind of thing. The aggregate() function lets you move > setOption & friends into a separate own options class and "inherit" > it at runtime when needed. is that going to be in the new php-version? if so it means this class would only be available using php from that version upwards, right? anyway, are there any ideas of where methods like those (setOption, getOption, getOptions, ... ) should go? i dont think they belong in PEAR.php, but where should they go? since the PEAR::DB uses it too, it would make sense putting it in some "common" place, what do you think? -- Wolfram