ENB: About immutable positions
Edward K. Ream
This ENB will try to make sense of Vitalije's idea of immutable positions. Let's call them Imps :-) Leo's Position and VNode objects must stay as they are. However, as a thought experiment, we can imagine adding Imps to leo.
Don't get your hopes up. Imps are not a good idea.
What would an immutable position be?
If I understand Vitalije, an Imp would continue to exist when the outline changes. Leo could implement imps as a pair of dictionaries. One dict would associate Positions with Imps; the other would associate Imps with Positions. Immutable positions would have global position indices (gpxs) similar to gnxs.
Leo's position class would have to keep these two dicts up to date when moving, inserting, cloning, or deleting nodes. It won't be easy, but this is a thought experiment.
What problems would Imps solve?
None, imo:
- Imps may become invalid if the underlying VNode disappears.
- Difficult code like c.deletePositionsInList doesn't get any easier.
- g.app.p_to_ap and g.app.ap_to_p suffice to restore c.p on startup.
- gnx-based clickable links moot the need for Imps.
Summary
Leo could (as a thought experiment) implement Imps as a pair of dictionaries.
Imps would exist in addition to Positions and VNodes. The Position class would have to keep the dictionaries up to date. That task would not be fun. Mistakes would be catastrophic.
Imps solve no urgent problem, nor do they solve existing problems more simply.
gnx-based clickable links moot the need for Imps. Let's find new ways to use Leo's new clickable links!
Edward
Edward K. Ream
My initial post in this thread showed how Leo could support Imps (Immutable Positions) without changing Leo's Position or VNode classes. I concluded that Imps were not a good idea :-)
Vitalije not-so-subtly implies that Positions are a blunder. This post refutes that notion.
Positions are the foundation of Leo's generators.
The great Bernhard Mulder proposed using generators such as c.all_positions and p.self_and_subtree. Much of Leo's scripting prowess is the direct result of generators.
Positions have a natural meaning.
Positions correspond to outline order in a fully-expanded outline. This easily-understood meaning carries over to the corresponding generators.
The algorithms of the Position class are solid.
Generators work because Leo's position class makes them work. The algorithms underlying generators are non-trivial, as you can discover for yourself. Leo's representation of positions makes the algorithms as straightforward as possible.
Summary
Positions give Leo much of its scripting power. Their meaning, representation, and algorithms are easily understood and as simple as possible.
It is insulting to imply that positions are defective.
Those who think they have a better way can create a Leo plugin or even a fork of Leo. They can then discover for themselves whether replacing positions would work. They do not need my permission for their experiments, and they need not convince me beforehand that their ideas have merit.
Waiting a year won't change my opinion. Only a complete demonstration of fully functional code could do that.
Edward
Thomas Passin
My initial post in this thread showed how Leo could support Imps (Immutable Positions) without changing Leo's Position or VNode classes. I concluded that Imps were not a good idea :-)
Vitalije not-so-subtly implies that Positions are a blunder. This post refutes that notion.
Positions are the foundation of Leo's generators.
The great Bernhard Mulder proposed using generators such as c.all_positions and p.self_and_subtree. Much of Leo's scripting prowess is the direct result of generators.