On Mon, Apr 14, 2008 at 1:01 AM, Kayvan A. Sylvan <[EMAIL PROTECTED]> wrote:
> > On Sun, Apr 13, 2008 at 06:31:37AM -0700, Edward K. Ream wrote: > > > It appears that Leo will, relatively soon, move to the unified-node > world. > > > > Compatibility with existing code and scripts should be no big deal. > > Indeed, unified nodes will contain .v and .t ivars, inited in the ctor > > as follows: > > > > self.v = self > > self.t = self > > [...] > > This is all really exciting and very cool! Oh, it's better than that :-) This would be a good place to update you all on last night's code bashing. It's not in the unified-nodes branch yet. It will be soon, in a files call NEWleoNodes.py, NEWleoFileCommands.py, etc. That way I can run leoPy.leo in the unified-nodes branch without problem. Notes: 1. I started the review/rewrite of the crucial position methods such as p.moveToX methods. They are the acid test: if they can be done, then everything else, including iterators, can be done. In fact, the new code is either unchanged or simpler than the old code. So it looks like the first, crucial test passes. 2. It turns out, as Terry suggested, that having a v.parents list is required so that we can quickly implement p.isCloned and p.v.isCloned. So the symmetry between parents and children will exist explicitly. 3. A few changes to the position class are required. - Each position will have a new ivar, p.childIndex, indicating the index of p.v in p.parent().v.children. This new ivar *replaces* the old v._next and v._back links. I hadn't realized this so clearly before. Do you see how clever this is? Positions allow us to reconstitute the sibling order for v, but *only* in the context of a position. - Similarly, p.stack contains tuples (v,childIndex), where v is the parent node, and childIndex is the position of v in v.parent().v.children. With old positions, p.stack contained just vnodes. - New positions now contain a "full" p.stack. That is, p.stack contains an entry for *every* parent of p. Old positions "optimized" this stack by only putting entries in the stack for clones. But a full stack is required now. Furthermore, having a full stack eliminates some very tricky and hard-to-understand code, namely p.vParentWithStack and the code that used it. 4. Last night I wrestled with the issue of how to find the hidden root node, the parent of all top-level nodes. This morning I came up with a clever solutions, one that would have spared us all considerable work previously. The trick is to require a 'context' argument to all vnode ctors. This will be a commander, but the *only* requirement for the context object c is that c.hiddenRootNode exist. In effect, the context is a lightweight adapter class. Had I come up with this solution earlier, I would not have bothered to remove the c argument from vnode constructors (or was it position constructors?) This would have saved everyone the bother of having to change existing code. Perhaps more importantly, re-imagining the c argument as a context means that the new node class is *already* essentially independent of Leo's commander class, which was the whole point of removing the c argument from the ctor. 5. Much of the tricky "link" code in the position and vnode classes just disappears. 6. It looks like the new code will work unchanged in both the DAG and graph worlds. Of course, the graph world must define different iterators, but we knew that. The hidden root node is optional in the graph world. If it exists, it denotes some designated top-level nodes, and allows those nodes to be siblings. But it need not exist, and perhaps should not exist in some sense: without it, *any* node is potentially the root of all traversals. But clearly, we can deal with these minor issues later. 7. I've removed the .v ivar from nodes. v.v should never exist in Leo today, so there is no need for this ivar. The new position class will still use the .v ivar, so p.v will still exist, and all the code that reverences v.t, p.v and p.v.t will just work. (Or almost all the code :-) I think that's about it for now. It truly is thrilling to be able to simplify and generalize this fundamental code. Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
