Re: wolframs packages

Lorenzo Alberton wrote: Sorry for the long quotes, but it's more comprehensive that way...

- containers detached by the core class (see below): xml, memory, any dbal...

-1 from my side :) - that's what I meant by "container implementations"

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.

Merely the same argument I'd use against containers... :) Let's see...

- 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.

True and agreed now.

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?

May be true for the to*() methods, serialize() and unfold() are kind of substantially (in my current implementation).

Where a child is linked against its parent, following and preceding node Which makes implementation of the versatile XPath accesors very simple:

beautiful.

Ouch - somehow your "beautifuls" hurt :)

- 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 :)

And I'd say we would have to test this issue enough to find out what has the best balance between speed and ease of use...

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.

True. I'll try to dive more into it over the weekend. Regards, Michael