On Mon, 23 Sep 2013 13:17:04 -0500
"Edward K. Ream" <[email protected]> wrote:
> Second, c.virtualRootPosition is a bad idea. The intention was to avoid
> special cases, but the proposal creates its own special cases. Given:
>
> p = c.virtualRootPosition():
>
> 1. what is p.h? p.b?
c.hiddenRootNode.h and c.hiddenRootNode.b, respectively. Currently
those are initialized to "<hidden root vnode>" and "" respectively.
> 2. what does p.self_and_subtree() return?
Ideally, same as it would anywhere else, if it were possible to
construct a sufficiently functional position for this task.
If c.virtualRootNode() is the only way to get this special position
(i.e. it's not returned by p.parent() or anything else), it's
specialness, to whatever degree it has to be special, wouldn't really
be a surprise.
Hmm, maybe c.proxyRootNode() is a better name.
> Third, it gives me the chance to emphasize the following: We can *add*
> items to Leo's API, and we can fix bugs in Leo's API, but we can never
> change Leo's API in any incompatible way, including function signatures and
> *any* aspect of how any function works. The reason: we don't know what
> scripts are already using the API.
If there's no way to get to this position other than c.proxyRootNode(),
we can be sure no scripts etc. are already using it.
I suggested it because if you asked this question:
How do you insert a node B in an ordered tree data structure
immediately before node A?
in a general context not specific to Leo or Python, a general answer
might be:
(a) you can't insert a node before the root node, (b) in other cases,
tell A's parent to insert the new node at A's position, pushing A
down one.
For hysterical raisins Leo's answer is quite different, and, until
today at least, much more complicated.
But now that I think about it, maybe Leo's unusual tree API can be made
less special casey (referring to special cases dealing with
top-level nodes) with p.insertBefore() (already done :-) and, hmm, is
it worth having p.insertAsNthSibling()?, so that where
nd = p.parent().insertAsNthNode(0)
will fail for top level nodes,
nd = p.insertAsNthSibling(0) won't?
(p.insertAsLastSibling() as well for completeness)
I've only just realized how much of the cumbersome special caseness is
covered by p.insertBefore() and maybe p.insertAsNthSibling().
A workable c.proxyRootNode() would still be great for cases where you
want to pass a position as an identifier for a set of siblings which
may or may not be top level nodes, but most of the times I've run in to
this it's the .insertBefore() thing that's been so heavy.
So, I don't think c.proxyRootNode() would create any problems, *if* it
was possible to implement in a way that created a position that wasn't
a landmine, but I think the hide-the-details methods .insertBefore()
and maybe .insertAsNthSibling() cover a lot of the cumbersome cases.
Cheers -Terry
> 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.
