On Mon, Apr 30, 2018 at 2:13 AM, vitalije <[email protected]> wrote:
Because we are not sure what and where can be broken when we change > something, most often we are fixing bugs using just minor tweaks, adding > guards here and there, adding more kwargs. That strategy may suffice for a > first-aid. But in long terms it accumulates more and more complexity and > over twenty years we have what we have. > Imo, Leo's code base is clean enough, in general, but... I think it might be wise (at least once in a while) to invest some time in > serious refactorings aimed at reducing accumulated complexity. > You have already simplified important parts of Leo's code. I will welcome further simplifications. > Keeping backward compatibility wherever is possible is great. But I wish > that we stay open also for the cases when breaking backward compatibility > in certain areas can bring great reduce of complexity. > I am open to that possibility. "Minor" or "interior" parts of Leo's API can probably change with little or no affect on user code. But some parts of the API are fixed: we aren't going to change the methods of p and c, except in a *strictly *upward compatible manner. Having said that, I'm not going to hide behind compatibility in my reply to your post yesterday. I'll consider all possibilities, regardless of their affect on the API, and see where that leads. In such situations, perhaps we may ask users to vote or to present their > reasons against breaking backward compatibility. > I agree, but I'm one user who will veto any drastic changes ;-) > I don't think it is wise to keep backward compatibility forever. > Imo, this may be the biggest question facing Leo's devs after I am gone. My first thoughts on this subject are the following: 1. It would be crazy to change the API of the Position and VNode classes. The payoff would not remotely justify a fork in Leo's code base. *Do not go there*. Imo, it is tragic that python decided to fork itself into python 3. The pain will be eternal. There were other alternatives (from future import x). Forking python was a huge blunder. Do not repeat that mistake! 2. Similarly, there is little reason to change the API of any Commander (c) methods that correspond directly to user commands. These methods do one well-defined thing, and existing code might well use them. 3. In general, the API of subcommanders like c.atFileCommands and c.fileCommands, etc, *could *be changed without much change to user scripts. See c.initObjects for the full list of subcommanders. Do *not* delete any subcommander,but refactoring is possible *within* subcommanders. As I have said several times, refactoring at.read, and indeed all of leoAtFile.py, might be desirable. But *please *do not change code just because you might not have written it exactly the same way. There are far more interesting things to do with Leo. If there is a chance to improve code quality or/and its readability by > breaking backward compatibility I would suggest keeping it for some limited > time, and announcing that it will be dropped in one of the next releases. > Sure. Deprecating method before killing them is desirable. And even this probably isn't necessary for the only-vaguely-defined helper methods. It depends on the probability that user code is likely to use low-level helpers. *Summary* *When in doubt, leave Leo's API unchanged*. Leo's users will thank you. Breaking Leonine code is the best way I know to blight Leo's future. 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 https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
