On Dec 17, 10:35 am, "Edward K. Ream" <[email protected]> wrote:
> Changing p.isExpanded would be a major change to Leo.
It's becoming clear that making sense of the graph world is going to
be far from trivial. The title of this thread is dubious :-)
Some thoughts:
1. This project would not have been possible last year--we didn't have
bzr and I wasn't comfortable with cvs branches.
2. A small aha: the expansion state of a node should be considered a
property exclusively of the tree-drawing code. This is the clean way,
and it leads to other insights.
3. We must be careful to distinguish between screen properties, like
expansion state, and iterator/position properties. In particular, the
expansion state of a node, being a tree-drawing property, is
*unrelated* to a similar property that would tell an iterator
(equivalently, position) whether to follow a back link or not.
As I write this, it would seem natural to adopt the rule that
iterators *never* follow back links. This rule may be too facile.
Consider the common case where A is it's own child. Under the no-back-
links rule, A will not show up in A.child_iter()! This seem wrong, as
I wrote yesterday. OTOH, it seems much more reasonable to insist that
A.threadNext() is never A.
5. Carefully distinguishing between screen expansion state and other
properties leads to the notion that graph world positions/iterators
must contain more history. p.stack does not suffice. In particular,
it would seem reasonable for c.allNodes_iter() to visit every vnode
exactly once. The no-back-links rule does not suffice either. For
example, the no-back-links rule would not prevent every top-level
clone of a node to be visited.
The only way to visit each node exactly once seems to be to record
which vnodes have been visited. There are several ways this can be
done:
1. The obvious way is for the iterator (equivalently position) to
remember which vnodes have already been visited.
2. Another way is for each iterator's ctor to bump a generation
count. Marking a vnode as visited would amount to storing that
generation count in a vnode ivar.
These appear to have similar storage requirements, so the first way
seems more straightforward.
Anyway, the main idea is this:
*screen expansion state is not the same as traversal cutoff state*.
This is good news: it means we can, and should, design iterators
without any regard for the screen drawing algorithm. Instead,
iterators should be designed to make accessing graph data easy. The
proposed design of c.allNodes_iter appears to do this.
Edward
P.S. In my first post on this thread I said:
QQQ
Unlike the general graph packages, Leo's iterators are *not* more
confusing in the graph world!! This is what mislead me for so long.
The difference is that Leo's graphs are *already* projected onto a
DAG/
outline. This *existing* projection provides the context in which all
iterators mean something obvious. We don't have to define "fancy"
iterators: the *tree* iterators are all we need.
QQQ
I still think this statement is true, but as we have seen it is far
from trivial to adapt tree iterators for use in graphs. In
particular, any change to Leo's iterators had better be guaranteed to
have no effect in the tree (legacy) world. We might prefer to have
separate versions of iterators for the tree and graph worlds, but such
a "mode bit", if made permanent, would be a permanent blot on the
design. For example, Leo scripts might behave very differently in the
tree and graph worlds. That may be in general no matter what we do,
but we would like to avoid such semantic differences wherever
possible.
In short, the redesign of Leo's iterators for the graph world is of
the utmost importance.
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
-~----------~----~----~----~------~----~------~--~---
