Re: Re: wolframs packages

> Hi Stefan Neufeind, you wrote: > On Thu, 3 Jun 2004 at 14:43:26, Michael Wallner wrote: >>> 3) Tree Generic tree management, currently supports >>> DB and XML as data sources >>> >> I'm already working on some PEAR::Tree alternative. Yeah, >> I know there's already Tree (competive packages etc...) and >> Wolfram may be a great visionaire, but his sources are always >> kinda messy and current Tree's API and object model is >> extra-ordinary complicated. having worked a lot with wolfram's code, I tend to agree :-) He is a tremendous code writer and his packages are really good in what they do. The downside is what Mike already said, the code is a bit messy and the object model could often be simpler. >>> Hmm, so I assume you have already worked with the current >>> Tree-implementation, when you discovered it's limitations? Then >>> maybe you would take over Tree and vastly improve it where >>> possible or if it really requires BC-breaks would build an official >>> Tree2 with extended functionality? > > Well I kind of tried to use it, but may be I'm too quickly dis- > satisfied. > Grepp'ing FIXX or TODO on pear/Tree counts 16 and i know that it is > not fun to dig into 170 kB of Wolframs code - it always seems to be > bursting at the seams with unfinished ideas. > > My implementation is object based and has yet about 40 kB and will > have, let's say, 60 to 70 kB when it's mostly finished. Because of using > objects it was fairly simple to implement kind of an XPath API with > ancestor(), ancestorOrSelf(), descendant(), descendantOrSelf(), > followingSibling(), > following(), precedingSibling() and so on (which are very usefull > when working with a tree - at least in my POV). It's a pity that I > didn't sync the latest sources with CVS and I'll return to this topic > soon. please keep me informed on this. I once hacked pear::Tree (an old patch can be seen in the bug list), and managed to add some feats without breaking the api, just moving some things around. I think a deep refactoring can lead to a simpler code structure without changing the API too much. Or, better yet, we could write a new version with a more streamlined design, but IMHO we should really try to reproduce and expand *all* the current features (i.e. db/xml/xpath, memory trees, nestedset+classic tree models, better support for different containers). If we want quality in pear, we should at least *try* to write the ultimate-tree-class(TM), as Wolfram's class was/is meant to be. I'm still a bit confused on how DB_NestedSet got into pear rep. To me, it looked like it could be easily integrated in pear::Tree with little effort, but the discussion was carried out in a confuse way, and perhaps not all the people involved realized that a similar feat already existed. (Note to db_nestedset devs: don't misunderstand me, I'm not saying your class is not good, I use it myself and appreciate many things, but I still think it could be integrated instead of writing Yet Another Pear Package). The good thing is pear::Tree is still beta, so API breakage is still allowed. Michael, if you plan to work on this package, I'd be glad to help (not as lead, though, the timeframe I can allocate for this project is *very* thin). Regards, -- Lorenzo Alberton http://pear.php.net/user/quipo