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

Author

[PEAR-QA] Re: wolframs packages

Stefan Neufeind

2004-06-03, 9:33 am

On Thu, 3 Jun 2004 at 14:43:26, Michael Wallner wrote:

> Hi Lukas Smith, you wrote:
>=20

[...]
[color=darkred]
>=20
> Hm, there's already I18Nv2.

I guess that's what Lukas meant.

>=20
> I'm already working on some PEAR::Tree alternative. Yeah, I know
> there's already Tree (competive packages etc...) and Wolfram may
> be a great visionaire, but his sources are always kinda messy and=20
> current Tree's API and object model is extra-ordinary complicated.

Hmm, so I assume you have already worked with the current Tree-implementati=
on,=20
when you discovered it's limitations? Then maybe you would take over Tree a=
nd=20
vastly improve it where possible or if it really requires BC-breaks would b=
uild=20
an official Tree2 with extended functionality?

Stefan

Michael Wallner

2004-06-03, 10:34 am

Hi Stefan Neufeind, you wrote:

> On Thu, 3 Jun 2004 at 14:43:26, Michael Wallner wrote:
>
>
>
> I guess that's what Lukas meant.

Yeah, I just meant "don't beat a dead horse". :)
AFAIK Martin has promised to work out a pearweb
patch for marking packages as deprecated.

VW doesn't build the old beetle anymore...

>
>
> Hmm, so I assume you have already worked with the current
> Tree-implementation, when you discovered it's limitations? Then maybe
> you would take over Tree and vastly improve it where possible or if
> it really requires BC-breaks would build an official Tree2 with
> extended functionality?

Well I kind of tried to use it, but may be I'm too quickly dis-satisfied.
Grepp'ing FIXX or TODO on pear/Tree counts 16 and i know that it is not
fun to dig into 170 kB of Wolframs code - it always seems to be bursting
at the seams with unfinished ideas.

My implementation is object based and has yet about 40 kB and will have,
let's say, 60 to 70 kB when it's mostly finished. Because of using objects
it was fairly simple to implement kind of an XPath API with ancestor(),
ancestorOrSelf(), descendant(), descendantOrSelf(), followingSibling(),
following(), precedingSibling() and so on (which are very usefull when
working with a tree - at least in my POV). It's a pity that I didn't
sync the latest sources with CVS and I'll return to this topic soon.

Regards,
--
Michael - < mike(@)php.net >

Lorenzo Alberton

2004-06-03, 11:34 am

> Hi Stefan Neufeind, you wrote:
> On Thu, 3 Jun 2004 at 14:43:26, Michael Wallner wrote:

having worked a lot with wolfram's code, I tend to agree :-)
He is a tremendous code writer and his packages are
really good in what they do. The downside is what Mike already
said, the code is a bit messy and the object model could often
be simpler.
[color=darkred]
>
> Well I kind of tried to use it, but may be I'm too quickly dis-
> satisfied.
> Grepp'ing FIXX or TODO on pear/Tree counts 16 and i know that it is
> not fun to dig into 170 kB of Wolframs code - it always seems to be
> bursting at the seams with unfinished ideas.
>
> My implementation is object based and has yet about 40 kB and will
> have, let's say, 60 to 70 kB when it's mostly finished. Because of using
> objects it was fairly simple to implement kind of an XPath API with
> ancestor(), ancestorOrSelf(), descendant(), descendantOrSelf(),
> followingSibling(),
> following(), precedingSibling() and so on (which are very usefull
> when working with a tree - at least in my POV). It's a pity that I
> didn't sync the latest sources with CVS and I'll return to this topic
> soon.

please keep me informed on this. I once hacked pear::Tree (an old patch
can be seen in the bug list), and managed to add some feats without
breaking the api, just moving some things around.
I think a deep refactoring can lead to a simpler code structure without
changing the API too much. Or, better yet, we could write a new version
with a more streamlined design, but IMHO we should really try to
reproduce and expand *all* the current features (i.e. db/xml/xpath, memory
trees, nestedset+classic tree models, better support for different=
containers).
If we want quality in pear, we should at least *try* to write the
ultimate-tree-class(TM), as Wolfram's class was/is meant to be.
I'm still a bit

on how DB_NestedSet got into pear rep. To me,
it looked like it could be easily integrated in pear::Tree with little=
effort,
but the discussion was carried out in a confuse way, and perhaps not
all the people involved realized that a similar feat already existed.
(Note to db_nestedset devs: don't misunderstand me, I'm not saying
your class is not good, I use it myself and appreciate many things,
but I still think it could be integrated instead of writing Yet Another Pear=

Package).

The good thing is pear::Tree is still beta, so API breakage is still=
allowed.

Michael, if you plan to work on this package, I'd be glad to help
(not as lead, though, the timeframe I can allocate for this project is=
*very*
thin).

Regards,
--
Lorenzo Alberton
http://pear.php.net/user/quipo

Michael Wallner

2004-06-03, 12:32 pm

Hi Lorenzo Alberton, you wrote:

[color=darkred]
>
>
> please keep me informed on this. I once hacked pear::Tree (an old
> patch can be seen in the bug list), and managed to add some feats
> without breaking the api, just moving some things around. I think a
> deep refactoring can lead to a simpler code structure without
> changing the API too much. Or, better yet, we could write a new
> version with a more streamlined design, but IMHO we should really try
> to reproduce and expand *all* the current features (i.e.
> db/xml/xpath, memory trees, nestedset+classic tree models, better
> support for different containers). If we want quality in pear, we
> should at least *try* to write the ultimate-tree-class(TM), as
> Wolfram's class was/is meant to be. I'm still a bit

on how
> DB_NestedSet got into pear rep. To me, it looked like it could be
> easily integrated in pear::Tree with little effort, but the
> discussion was carried out in a confuse way, and perhaps not all the
> people involved realized that a similar feat already existed. (Note
> to db_nestedset devs: don't misunderstand me, I'm not saying your
> class is not good, I use it myself and appreciate many things, but I
> still think it could be integrated instead of writing Yet Another
> Pear Package).
>
> The good thing is pear::Tree is still beta, so API breakage is still
> allowed.
>
> Michael, if you plan to work on this package, I'd be glad to help
> (not as lead, though, the timeframe I can allocate for this project
> is *very* thin).

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

I tended to use DB_NestedSet for the DB implementation, but I have not
checked yet if it provides the proper API for implementing the XPath
accessors, which should be provided by *each* Tree implementation,
although preceding() is a really tricky one, because of the order
the nodes should be returned... :)

Lorenzo, listing the features you liked so much about Tree would
help pretty much already for now.

What I really don't like are these "container implementaions" which
tend to duplicate the API and make everything more difficult than easier...

---
PS: Hey PEAR-QA (listed in no particular order):
Klaus Guenther, Lukas Smith, Stefan Neufeind, Arnaud Limbourg,
Helgi Þormar, Stephan Schmidt, Tobias Schlitt, Antônio Carlos,
Venâncio Júnior, David Costa, Aidan Lister, Davey Shafik,
Peter Prochaska, Christian Wenz, Cipriano Groenendal

Have a look right here and fire up your patch program:
http://cambiano.onlinein.it/pearzone/Tree/

Regards,
--
Michael - < mike(@)php.net >

Lorenzo Alberton

2004-06-03, 2:32 pm

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

Sponsored Links