different "core"?

Post #107,322

6/25/03 9:07:51 PM

6/25/03 9:09:55 PM

different "core"?

In a pure OO world, the data could simply be defined as an object which responds to a suitable method. Well, while PHP's object infrastructure would support this, the rest of our app isn't pure written OO-style. Besides, these Trees are going to be created, displayed and then discarded in the same page. So we decided on a callback function: the display function takes as one of its parameters the function name which it calls for every node. The callback function is given the opaque data of the node in question as well as some optional extra information (to eliminate global variables) - all it has to do is output what is to be displayed.

I am still unclear as to why you need a closure. I suspect it is that you have complex tree traversal code, and you don't want to repeat it for each different use of the tree. Therefore, you pass the "core code" in the form of a function pointer to this complex looping or recursion thingy.

The simplistic solution is perhaps a Case structure in the middle of the loop or recursion. If you only have say 3 different processing options and they don't add new ones very often, this may work.

The "ideal" TOP solution would be to use a RDBMS that can traverse trees without coding recursion. (Oracle has this I beleive, but I cannot vouch for its friendliness.) If all usages use the same query, then simply have a global string or function to share (reuse) the same query. It is then no different from any other query-and-iterate-result-set pattern. Unfortunately, Dr. Codd excluded tree operations from his original relational operators.

________________
oop.ismad.com

Edited by tablizer June 25, 2003, 09:09:55 PM EDT

Expand All History

Post #107,472

by static

6/27/03 7:42:08 AM

That's one way to think of it.

The point of passing the function is that code to display the tree is entirely unaware of what the data is in the nodes. It simply doesn't care because it doesn't have to care - all it needs to be concerned about is that there is a function to call. Putting that logic in the walk-the-tree code does not make sense because that location is how the tree works, not where I use the tree. (Incidentally, the recursion is peripheral to the example: it's prime purpose is to permit the tree to be an arbitrary depth.)

A closure is like passing a pointer to a function, except that the function is anonymous (i.e. has no name) and is defined right where you would specify a pointer-to-a-function if the language doesn't have closures. They're sometimes called lambda functions.

Wade.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed

Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

Post #107,662

by tablizer

6/28/03 12:27:03 AM

But if tree traversal was trivial, then it does not matter

If the relational system supports tree operations, then it is as simple as:

----Usage 1:

rs = getTreeTraversal()
while (getNext()) {
. . doSomething_1
}

----Usage 2:

rs = getTreeTraversal()
while (getNext()) {
. . doSomething_2
}

----Usage 3:

rs = getTreeTraversal()
while (getNext()) {
. . doSomething_3
}

The problem you are having is that the bread is more complex than the meat of the sandwich. Simplify the bread (tree traversal), and using tricky closure meat is no longer so important.

In practice, we probably want different filtering, cross referencing, etc. for each usage. That is where custom relational queries would shine. One-size-fits-all traversal is not that likely if there are many usages.

________________
oop.ismad.com

Post #107,674

by static

6/28/03 8:51:24 AM

It's a matter of perspective.

Using your coding style, my solution looks like:

rs = getTreeTraversal()
displayTree(rs, displayFunction)

function displayFunction(item) {
. . doSomething_1
}

Which one is easier to implement depends on the details of walking the tree*. The more state that must be kept between touching each node, the easier it is to implement it my way, although that is not the only consideration. (BTW, tree traversal need only look trivial for the code using the tree.)

Actually, implementing this with a closure makes it look like your example, but it works more like mine: you get the advantage of a loop-like construct in both places.

Wade.

* although I've let it slide 'till now, whether or not the tree is database-backed or just in-memory is not important in my example.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed

Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

Welcome to IWETHEY!