On Tue, Aug 3, 2010 at 2:20 PM, Ville M. Vainio <[email protected]> wrote:
> The convenience is not minor - the original API is not something that
> should be published at all (i.e. it should be a private method).
I do not entirely agree, but nevertheless I've followed this
suggestion at rev 3200. The new code is almost as simple as the old::
def deletePositionsInList (self,aList,callback):
# docstring omitted.
p = self.copy()
while p and aList:
if p in aList:
aList.remove(p)
for z in aList:
if p.isAncestorOf(z):
aList.remove(z)
next = p.nodeAfterTree()
callback(p.copy())
p = next
else:
p.moveToThreadNext()
As you can see, aList continually gets shorter, so there is a tiny
speed improvement in the test 'p in aList', at the cost, of course, of
removing descendant nodes from aList. I suspect speed will never be
an issue.
Nevertheless, I am a bit uneasy about the new api. The explicit
afterLastNode no longer exists, so there is no easy way to describe
the range of the traversal. This doesn't *necessarily* have to
matter, but it could matter, and it might lead to some nasty bugs.
True, there can be no problem in the "natural" case, in which the
callback just deletes the node. But trying to describe the
circumstances in which *moves* are safe brings us right back to the
range defined by p and afterLastNode. So the easy cases are
simplified, while the harder cases might be obscured.
In any case, I think we can live with the newest code. I don't plan
any changes unless there are real bugs.
Edward
P.S. As I write this I see that we could define a default callback
that would just delete the node. Might as well do it.
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.
