On Tue, Jun 16, 2009 at 7:16 PM, Edward K. Ream<[email protected]> wrote:
>> - Have identity (gnx) >> - Can be cached > > The problem with unified nodes is that they are, well, unified. All clones > *are* the same node. That means that if you mark one (v)node, you must mark > them all: their position within the outline no longer matters. But, also remember that for vnodes (as opposed to positions), it's the same thing. The same vnode *will* be in multiple positions if it's in a cloned tree. The only places where vnodes are unique are the ones where you branch out to a clone. > I personally think this is a minor issue. Using or not using unified nodes > just can't make a big difference. If it's pretty much the same thing, it would be better to use the simpler model (and code) that works in same fashion, right? Right now, the vnodes cause unnecessary confusion because they promise more than they deliver. vnodes are not positions, nor can they be used in the same fashion. What they buy us over tnodes is complexity and redundancy in runtime data structures. The complexity is a valid concern, since I've seen a lot of confusion about the vnodes even among the longtime users on this mailing list. And, I have been severely confused myself. At the moment this is just a distraction from getting the release out, but do leave it in the back of your subconscious :-). -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
