Re: wolframs packages

Hi Lorenzo Alberton, you wrote: > 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 Yeah, seems that you have worked quite a lot with the current PEAR::Tree, and that you are (kind of) used to its implementation and concept. The concept I have in mind is totally different of yours, though. Just let me say one word beforehand: KISS - yeah I know it's a buzzword, but it was the reason why I started the work on Tree_Lite (that's just the current name), but let's elaborate a bit. >>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) Maybe I didn't think well enough about it yet, but do you see any other backend than RDBMS where a nested set model is "necessary"? > - containers detached by the core class (see below): xml, memory, any dbal... -1 from my side :) - that's what I meant by "container implementations" Things like: class Tree { var $container; function Tree($type) { $this->container = new Tree_$type; } function doSth() { return $this->container->doSth(); } } lead to API duplication and needless hours of work. I'm more in favour of classes implementing common methods and extending classes, e.g.: class Tree { function method() { // do common work } } class Tree_Sub extends Tree { function method() { // do sth particular - override just if needed } } > - 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). Bloat. :) Sounds like an app to me. I cannot see any benefit in separating "writing" code from "reading" code, but that's most probably because I didn't explain the architecture of my current implementation: Current Tree operates on an huge array AFAIK. Separating for a tighter API might be reasonable in this case. My Tree's heart is the Tree_Node which implenents the whole "executive" API. The Tree "class" holds just the root node and provides some common methods like factory(), unfold(), serialize(), toArray(), toString(), toFile(), raiseError(), setOptions(), fromNode() etc. overriden in special cases by the extending Tree implementation. Of course some generic accessors should be implemented too. ASCII visualized a Tree would look sth similar to that: Tree + root + childs + child | + childs | + child | + child + child + child + child Where a child is linked against its parent, following and preceding node: parent | +--------+---+----+--------+ | | | | child child child child ^ | | ^ +-------+ +-------+ preceding following Which makes implementation of the versatile XPath accesors very simple: class Tree_Node { function &ancestor() { if ($this->parent) { $ancestor = &$this->parent->ancestor(); array_unshift($this->parent, $ancestor); return $ancestor; } return array(); } function &ancestorOrSelf() { $ancestor = &$this->ancestor(); array_unshift($this, $ancestor); return $ancestor; } } echo "\nXML path: "; foreach (array_reverse($xml_node->ancestorOrSelf()) as $node) { echo '/'. $node->name; } > - possibility to reorder siblings, in the admin class > (already implemented in DB_NS) Could be easily done by "relinking" the childs. > - internal datatype implemented as arrays, optional output > wrappers/decorators (object or whatever): until php5 is widespread, > we have to deal with intrinsic object slowness... Well, I think driving an object tree is more beneficial, but hey I'm open minded (sometimes, kind of :) I'll comment the rest of your mail later :) - have to go now. > - 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... PS: bah, CC! >-| ;-D Regards, -- Michael - < mike(@)php.net >

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc