On Thursday, March 7, 2019 at 10:58:58 AM UTC-6, Edward K. Ream wrote: pyzo is a major app. It's not clear how to move any part of pyzo's code > into Leo. >
Some further thoughts on this topic... *Questions* The first stage will be investigating the pyzo code. I want to know: - What happens on startup and shutdown? - What is the Qt widget hierarchy for an empty pyzo window? - What connections (messages) are their between pyzo objects? - What are the relationships between members of base classes of CodeEditor class? These are all preliminary to the big question: what's the best way of moving pyzo code into Leo? *Avoid premature code choices* It's fine to explore indefinitely. Committing to any code strategy prematurely promises to waste a lot of work. *Unraveling multiple inheritance* The CodeEditor class is an extreme example of the "is a" pattern. All members of its base classes *are* members of the CodeEditor class. Python has rules for disambiguation, include class name mangling, but I am not a fan of this pattern. In principle, it's straightforward to use the "has a" pattern by instantiating new *inner objects* within CodeEditor, one for each base class. Each inner object (instance of a base class) would have an *editor *ivar. Inner objects would reference *outside members* by self.editor.x, where x is a *remote inner object*. In practice, we expect few references to remote inner objects, because we expect the base classes to be fairly well encapsulated. Otherwise, what is the point of all these base classes? And we expect only a few stylized remote references. Imo, the great advantage of the "has a" design pattern is that all remote references are explicit. There is never the slightest doubt about what is being referenced. So I can *consider* using the "has a" pattern to eliminate multiple inheritance. The "avoid premature code choices" principle tells me to explore the implications thoroughly beforehand. Happily, this is *relatively* easily done. I'll write a script that will detect all remove references in all the base classes of CodeEditor. It can probably be done in a few hours. The scrip will reveal, explicitly, all the implicit connections in the nest of CodeEditor classes. The results will be organized in an outline, something like the git-diff command does. *Important*: I do not intend to use any form of the CodeEditor class in Leo. That doesn't make a lot of sense, and it would be too big a change in any case. However, I do plan to use several of the base classes. This suggest that using the "has a" pattern may be worth doing. *Bindings* The thoughts in this section would never have occurred to me without Vitalije's comments. A big reason that code is hard to reuse is that code exists only in contexts in which all vars are fully bound. Vitalije and I disagree slightly about how many of those bindings should occur implicitly, but that's a nit. In essence, code containing unbound references, *including self*, is exactly useless. The typical Python style is to put almost everything in classes. Instantiating classes is one form of binding. Other languages use other methods, including closures and patterns to bind vars. In any case, *everything must eventually be bound*. The most difficult case is startup, because there is so much to be bound all at once. Worse, *binding order matters*. Lazy binding is no panacea because even lazy bindings happen *sometime*, and all bindings needed by a lazy binding must be available *then*. Yes, we can use lazy binding to get *those* bindings, but there is a real possibility of a circular list of binding dependencies. The finishCreate pattern is one way of breaking circular dependencies. Other ways are possible. What we *can't* do is pretend that binding order doesn't matter. *Summary* I'll be asking many questions of the pyzo code. The goal is to avoid premature code choices. I must resist, as long as possible, to start cutting and pasting code ;-) I'll write a script to investigate the *actual* dependencies between the base classes of the CodeEditor class. I want to make these dependencies implicit and easily seen. Reusing code is nontrivial. Leo must (somehow!) make all the bindings pyzo makes. 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.
