On Sat, Jul 4, 2009 at 3:18 PM, Ville M. Vainio <[email protected]> wrote:
> > positions are relevant as tree iterators (in the meaning of "positions > on screen"), but are no longer a necessary middleman for all tree > operations for "bookkeeping". Actually, this statement is just plain false, as I was reminded yesterday. I'm going to insist on accuracy just now, because it will guide me in designing the one-node world. The best guide, I think, is the picture that brought the unified nodes world into being several years ago. The picture is of a hand holding seeds. The fingers are positions; the seeds are nodes. The outline is the hand and the seeds. We must have both at all times. In another reply I said: > you could say that the union of all v.children arrays defines the outline's structure. Depending on what these are allowed to contain, we could get a (strict) tree, a DAG, or a general graph. This is, and must be, strictly true. That is, v.children is the *only* primary data in a one-node DOM. Everything else is "helper" data. In particular, v.parents is derived from v.children, not vice versa. It's not even clear that v.parents will be useful in the one-node world. Let's consider the consequences of that fact that cloned nodes are actually exactly the same node. In the following, I'll consider the terms "vnodes" and "nodes" to be synonyms. 1. A node can appear arbitrarily many times within an "outline". Equivalently, a node can appear arbitrarily many times in the traversal defined by c.allNodes_iter. 2. A node can have arbitrarily many parent nodes. In a general graph, a node may be its own parent. 3. The same node v can appear multiple times in parent_v.children, for some parent_v. Indeed, cloning a node always produces two siblings which will be (in the one-node world) the same node. Later, the user can move one of those siblings so it becomes a child of another parent. As a result of these and similar statements, the **only** tree-related data one can deduce about a node v is v.children, v's direct children. In particular, it is **not possible** to determine (without a position) any of the following: - v's siblings. - v's direct parent. - v's descendants. Actually, in a dag, it is possible to determine v's descendants, but it's probably not possible to determine v's descendants in a general graph without knowing which links have already been followed. Happily, many of these statements already have influenced Leo's code. In other words, Leo's present code will naturally lead me to code that works in such an environment. I hope this clarifies the essence of the situation, namely that in the one-node world, just as in the present world, the fundamental code in leoNodes.py must be based primarily on positions, not (v)nodes. Edward P.S. It is still an open question how much of the fundamental position methods in leoNodes.py will have to change. However, I strongly suspect that the move to generational marking will likely affect the crucial p.moveToX methods. EKR --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
