Re: Re: wolframs packages

On Thu, 03 Jun 2004 17:14:51 +0100, Michael Wallner wrote: > Phew. :) did I exaggerate? Yeah, maybe I heated myself too much. I often tend to, for packages I care about :-D :-D > I'd really appreciate your help, Lorenzo - but I have to warn you, > because I can really become a pain in the ass when CS is concerned > Just let me sync my CVS tonight... oh, no hurry. As I said, I'll probably take my time too ;-) > Lorenzo, listing the features you liked so much about Tree would > help pretty much already for now. going by heart, these are the feats I consider important and I'd like to have: - common API for parent/child and nestedset models (doable with a factory and two classes implementing the same interface) - containers detached by the core class (see below): xml, memory, any dbal... - admin interface (for adding/moving nodes) detached from the core, which should be as small and as fast as possible (i.e. an "Tree_Admin extends Tree" approach would be best). - custom # of levels returned in getBranch() (trivial, but still unimplemented in both Tree and DB_NS, IIRC) - possibility to reorder siblings, in the admin class (already implemented in DB_NS) - internal datatype implemented as arrays, optional output wrappers/decorators (object or whatever): until php5 is widespread, we have to deal with intrinsic object slowness... - different traversal algorithms, an iterator interface would be nifty. - basic getters (getNode, getRoot, getChildren, getSiblings, getParent, getAncestors, getBranch, getPath, getDepth/Level). there's probably more, but it can be enough for now :-) The idea is: a minimal (and I mean it!) core class, an extended admin class for tree manipulation, and some decorators to provide output filters (such as datatype conversions and field masking). The containers should be pluggable. > What I really don't like are these "container implementaions" which > tend to duplicate the API and make everything more difficult than > easier... agreed, I had to jump more than once to implement a mdb driver in current pear::Tree. The problem is the support to more containers was not planned at all in the original code. But if designed properly, it can be trivial to implement. All we need is a common interface, aka a stub, to proxy driver-specific calls. I did so in Translation2, it hasn't been difficult :-) cheers! -- Lorenzo Alberton http://pear.php.net/user/quipo PS: please CC me, I'm not subscribed to the list, I only read the newsgroup archive every now and then...