PHP PEAR Questions and Answers - Re: [PEAR-QA] wolframs packages

Author

Re: [PEAR-QA] wolframs packages

David Costa

2004-06-03, 9:33 am

On Jun 3, 2004, at 2:35 PM, Lukas Smith wrote:

> Hi,
>
> Wolfram is appreantly very busy and would therefore be willing to have
> other people take over his packages.
>
> 1) HTML_Template_Xipe A simple, fast and powerful template engine.

seen the general adversity toward so many template engines, it might
be the case to remove this from the public directory.

Cheers
David Costa

> 2) I18N Internationalization package
> 3) Tree Generic tree management, currently supports DB and XML as
> data sources
>
> I will try to get in contact with Richy regarding I18N, but I assume
> he is not interested in that package anymore.
>
> regards,
> Lukas Smith
> smith@backendmedia.com
> _______________________________
> BackendMedia
> www.backendmedia.com
> berlin@backendmedia.com
>
> Linn Zwoch Smith GbR
> Pariser Str. 44
> D-10707 Berlin
>
> Tel +49 30 83 22 50 00
> Fax +49 30 83 22 50 07
>
> --
> PEAR QA Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Michael Wallner

2004-06-03, 4:33 pm

Hi Lorenzo Alberton, you wrote:

> On Thu, 03 Jun 2004 17:14:51 +0100, Michael Wallner wrote:
>
>
>
> 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.

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

Lorenzo Alberton

2004-06-03, 5:33 pm

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

>
> -1 from my side :) - that's what I meant by "container
> implementations"
>
> Things like:
>
> class Tree {
> var $container;
> function Tree($type) {
> $this->container =3D 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.

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

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

Michael Wallner

2004-06-04, 3:57 pm

I wrote:

> I'll comment the rest of your mail later :) - have to go now.

Uhm, I'll have very limited internet access during the w

end,
so, I'll probably just log in to flush CVS and to look for very
important mails - sorry.

For those who are interested, the prototype of what
I had in mind can be viewed online at:

http://cvs.iworks.at/cvs.php/classes/Tree_Lite/Tree

Regards,
Michael

Michael Wallner

2004-06-04, 8:56 pm

Lorenzo Alberton wrote:

Sorry for the long quotes, but it's more comprehensive that way...

[color=darkred]
>
>
> 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.
>
>
>
>
> 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...

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

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

>
> beautiful.

Ouch - somehow your "beautifuls" hurt :)

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...
[color=darkred]
> 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 w

end.

Regards,
Michael

Michael Wallner

2004-06-04, 8:56 pm

I wrote:

> Lorenzo Alberton wrote:

>
> Ouch - somehow your "beautifuls" hurt :)
>
>
>
> 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...

Beautiful slow! :)
Yes its a few times slower than the array approach.
/kick Tree_Lite

I think it would be far better to start off from Wolframs code base.

Regards

Sponsored Links