On Sun, Feb 5, 2012 at 7:07 AM, <[email protected]> wrote: > Why not just have .s attribute in KeyStroke, that contains the string > version?
A good question. Indeed, all Keystroke objects ks do have an s ivar. Experience (that is, ugly code) has shown that *during* the transition we don't want to have two versions of the code, one using stroke (a string) and the other using ks.s. *After* the transition, that is, once the new_strokes switch goes away, we could, in fact, use ks.s instead of ks. However, it's cleaner just to use ks and not have client code know about ks.s. More importantly, too much code manipulates stroke (or ks.s) objects. This is a symptom that the details key handling (whether represented as a string or as a KeyStroke) have "bled" into the areas of the leoKeys code where they do not belong. This is far from a theoretical problem. A lot of code in leoKeys.py deals with the picky details of the representation of key strokes. This is a great violation of the Don't Repeat Yourself principle and makes the code "sclerotic": rigid and inflexible. I am convinced that the present work will greatly simplify what is, at present, by far the most difficult and poorly designed part of Leo. A capable KeyStroke class is a very important first step. I'll say more about this class 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.
