On Sat, Jul 4, 2009 at 4:05 PM, Ville M. Vainio <[email protected]> wrote:
> > If you have a simpler scheme in mind, definitely. The simplest thing that could possibly work would be refcounts in vnodes. This is the "cache" that must be updated when nodes are linked and unlinked. It may be equivalent to a central cache, but having this data be part of a vnode is much better design, imo. In this scheme (and in all previous schemes, for that matter), linking or unlinking a node has the side effects of updating all the refcounts in all the nodes in the linked/unlinked tree. In the past, the "refcount" was v.tnodeList, but in the new scheme a simple refcount will probably be best. Moving a node provides the opportunity for an optimization: rather than treating a move as an general unlink followed by a general relink (which would decrement and then increment the refcounts in all nodes of the moved tree), a move *might* simply update the refcounts of the top-level node. We shall see whether this optimization is worthwhile. > And, we already have equivalent structure (tnodesdict). It's needed to > detect clones in @thin node reading. tnodesDict is a necessary evil. It exists only during reading. I want to avoid global data structures like tnodesDict at all costs. Edward --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
