On Monday, January 13, 2014 11:59:39 AM UTC-6, Edward K. Ream wrote:
>
>
>
>
> On Mon, Jan 13, 2014 at 9:26 AM, Edward K. Ream <[email protected]>wrote:
>
> >
> All the hard work is complete!
>
Alas not. Moving existing organizer nodes is turning out to be quite a
puzzle.
> 1. The hard part of the code involves moving nodes.
Indeed it does, and moving already-existing organizer nodes is even more
complex.
The code will probably have to must distinguish between "bare" and
"non-bare" existing organizer nodes. And there are two *other* flavors of
existing organizer nodes:
1. imported organizer nodes: nodes whose children are created by the
importer itself (example: a class node will be the parent of its methods).
2. nodes created by @existing-organizer: nodes.
Here, I would like to discuss in a bit more detail a "factoid" that I just
mentioned on #leo.
Theorem: Any position can be moved provided *only* that both p's parent
vnode and p's childIndex are correct.
In particular, suppose p2 is a (possibly out-of-date) copy of p, which may
have moved. We can move p2 correctly to a new location provided only that
p2's vnode and childIndex are the same as those in p.
Proof: All the "real" work in moving a position happens in the low-level
vnode methods v._cutLink and v._addLink. These methods take only two
arguments:
1. parent_v, the result of calling p._parentVnode, defined as follows::
def _parentVnode (self):
'''Return the parent vnode or the hiddenRootNode if there is no
other parent.'''
p = self
if p.v:
data = p.stack and p.stack[-1]
if data:
v, junk = data
return v
else:
return p.v.context.hiddenRootNode
else:
return None
2. childIndex, that is, p._childIndex.
We can link and unlink any position p, provided only that p._childIndex is
correct and p.parent_v (p.stack[-1][0] or the hidden vnode) is correct.
Corollary: We can correctly move a copy p2 of a position p (even if
position p has changed since p2 was made!) *provided* that neither p's
parent nor p's childIndex have changed since p2 was made.
===== Summary
This corollary is likely why even the new_auto code that *doesn't* deal
with existing organizer nodes works. The code *does* preserve the
parent/child relationships where needed, and that is all that is needed to
do the "moves of moved positions". These consideration will be even more
important when moving even more nodes, namely existing organizer nodes,
however they are created. (A lot of gory details omitted.)
It is usually bad design to rely upon (or even to know about) such esoteric
considerations. But the new_auto code really has no alternative. True,
the code could attempt to do all the moves using low-level vnode code, but
that hardly seems like an improvement! The new new_auto code, by it's very
nature, changes lots of vnode links "at the same time". The *only* way of
getting the job done is by being clear about what links do, and do not,
matter.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
