Re: Tree-class for PEAR

On Fri, 2002-02-01 at 17:10, Wolfram Kriesing wrote: > > 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??) If that is important to you, sure. Just mail me the *,v files. > 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 Classes of the form Foo_Common are used to implement common functionality for other Foo_Xxx classes. In this case, it seems to me that Tree is designed to be a base class for about any kind of tree class, not necessarily just Tree_Xxx. So if Tree is truly generic, I think it should simply be called Tree. Sterling, I assume you have _at least_ one way of dealing with trees in ADT, what do you think? > > 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? aggregate() will be in 4.2. Another option would be releasing it as a PECL extension, but I'd rather not. > 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? IMHO PEAR.php should be as tiny as possible, I'd rather take stuff away from it than adding more. A separate Options or PEAR_Options class could work, although I don't fancy crowding the "PEAR" namespace too much. - Stig