On Jan 26, 1:50 pm, "Edward K. Ream" <[email protected]> wrote: > On Jan 26, 1:39 pm, Terry Brown <[email protected]> wrote: > > > Not really sure how the fundamentals of OO arose from fixing Leo's menus :-) > > The path is direct: I've spent most of the last week dumping Leo's > key-related data structures (mostly dicts). It's not enough to know > that a dict is a dict: I've got to know what the keys and values are, > and if the values are lists, I had better know exactly what the types > of list elements are.
Indeed, the situation is even more "interesting". Leo's key-handling code shows that even knowing (for sure), the Python type of an object is far from sufficient to ensure any kind of correctness in the code. Indeed, the representation of keystrokes is, at present, just a Python string. But this causes serious problems, because the picky details of how the keystroke is formatted make a big difference. Get this formatting wrong and a bug results. Instead of using "raw" strings, Leo's key-handling code urgently needs a KeyName class. The ctor would "canonicalize" the keystroke name for internal use, and various getters would deliver the name formatted as required for various well-defined situations: - toHash: delivers the name for use as a dictionary key. - toGui: delivers the name in the format the gui expects. - prettyPrint: delivers the name for the print-bindings, print- commands, etc. This would make a real difference in the reliability of Leo's code. For example, it appears that there are bugs lurking in Leo's key dicts that arise because the hashes are not properly canonicalized. Notes: 1. The analogy between g.Bunch and str is exact. Both are catch-all classes that obscure key distinctions. Either may be symptoms of missing types. 2. It's not enough to KeyName class, even with extensive unit tests. The code must use the class correctly. 3. I have always had a prejudice against "small" classes, which I suppose means classes that "merely" encapsulate a simple data structure. This discussion shows that this prejudice is simply wrong: what counts are the operations that the class exposes. 4. Even "small" classes may have significant implications for type inference. Using them in Leo may enable pylint or other tools to make important deductions. 5. Introducing the KeyName class just now would be dangerous. My plan is to continue to fix the key-related bug, developing unit tests as I go. I'll release the code, then consider retro-fitting it with the KeyName class, as well as other settings-related classes to be discussed in another thread. 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.
