Re[2]: [PEAR-DEV] PEARtree

Tomas V.V.Cox wrote: >> More generally spoken, the business sectors are nodes of a tree and >> the addresses (or any other information objects with properties) the >> leaves. TVVC> Do you mean one leave object per property? No, I shouldn't have introduced these properties at this point. A leaf object of the Tree library does have only a few properties - it knows about the node(s) it is assigned to, maybe some additional information (statistics, you mentioned silblings) and it carries a reference to an object. The objects which are referenced by the leaves are those which we as developpers want to arrange in a tree-like structure. But the Tree library doesn't care about what kind of objects the leaves reference. You can not alter the referenced objects through the Tree library (it wouldn't know how to do that). The Tree library manages references to objects - not the objects themself. TVVC> Why not directly properties TVVC> in node? You are right: the disctinction between nodes and leaves isn't necessary. However, it makes it easier to implement a restriction like 'a node can point to other nodes xor leaves, but not both'. Or statistics like how many leaves below this node? >> This is why I consider implementing a library for maintaining such >> hierarchical information trees. It shall be PEAR compliant (not only >> because it then might qualify for a really nice name: PEARtree :) >> >> The idea is this: 3 main classes: Tree, Tree_node and Tree_leaf - each >> extending DB_storage. Tree will take care of all >> modifying/adding/deleting of Tree_node and Tree_leaf objects which >> belong to this particular tree. TVVC> As the tree data structure is a very nice idea, it could be great if it TVVC> could contain more generic data, not only objects from a query. For TVVC> example I recently publish the Xml2obj class (in pear/Experimental/XML), TVVC> that maps an xml file to a tree of objects (dom style). With the tree TVVC> class I could bypass some current limitations of it, like a better node TVVC> search mechanism or the ability of one node to know about its parent or TVVC> brothers. The Tree library should be a able to store its structure through a interface. The meaning of the above mentioned reference can be any - a primary key in a table, a path to a file and so on. This way the library can be used for any kind of data. To think of the leaves and nodes as classes extending DB_storage was probably not a good idea: each DB_storage descendant invokes its own SELECT statement on the database. This could lead to performance problems with large trees. Correct? Yours. Jens