Re: wolframs packages

On Thu, 03 Jun 2004 21:12:41 +0200, Michael Wallner wrote: > 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. To clarify: I'm not *that* used to the current implementation, and it doesn't match my vision either. But I care about the *concept* of having a good Tree package in pear, not about the package itself, especially in its current form. In the past I tried to fix some things that I didn't like, but I was tied not to break the current API, so there was no room for structural changes. > Just let me say one word beforehand: KISS that's precisely my idea ;-) A simple, simple, simple base class. All the funcy stuff does not belong there. > - 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"? maybe not, but the most common usage of Trees is in combination with databases. And having a simple parent/child API for simple cases, and the ability to switch to a nestedset-based storage when performances require it, without having to change too much code is IMHO really important, and not that difficult to achieve. Anyway, not all the containers have to provide both models, if one of them is not useful or if it doesn't make sense. >> - 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. nah, it's just a matter of proxying a few calls... No API duplication, and not that time-consuming Anyway, I have no strong opinion here. > 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 > } > } That would imply you tie the base class to a specific container. Or your base class acts as a mere interface... Another downside: you have to duplicate a lot of code in each extending class. If a method in the base class has one line calling a container-specific method, you have to override the whole method. With my approach, the containers would only implement a few basic methods, so they would be lightweight, and the base class would handle all the processing logic that is not related to merely fetching the data. >> - 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, my idea is: if you don't need something, why should you load and parse it at each request? When I design a class, I tend to think about its concrete usage. When do I need tree manipulation functions? Mostly when I'm working on the admin side. What do I need most of the time, i.e. when presenting the data? Only the fetching functions, nothing else. See why I think separating the two things may have sense? Looking at current DB_NestedSet.php source, half of the code handles manipulating functions. >1000 LOC that I must parse even if I don't need them. > 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. I have to look at the source to understand what you mean. Are you proposing a SAX like approach? That's how every container should act, except the "memory" one, of course... Anyway, I really think that methods like toString(), toFile(), toArray(), toObject(), serialize(), unfold() don't belong to the base class. They're just output decorators, aren't they? > Where a child is linked against its parent, following and preceding > node > Which makes implementation of the versatile XPath accesors very > simple: beautiful. >> - 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. looking forward to :-) BTW: is the code in your cvs rep already? Do you mind if I have a look? Perhaps we have many points in common, but express them in a different way... Uh, another thing I probably didn't mention in my previous mail: if we are going to replace the existing class, probably we should provide everything the old class provided, or we can't propose it as a "replacement", if it lacks any of the existent features... just a thought. -- Lorenzo Alberton http://pear.php.net/user/quipo