This is a follow-on to the previous post: summary of Leo's key-handling code.
Interestingly, static type checking would shed little light on this design; the types of widgets passed (in the event arg) to k.masterKeyHandler hardly matter: k.getPaneBinding examines only:: - g.app.gui.isTextWidget(w), True if w supports Leo's HighLevelInterface. - c.widget_name(w), the pane's name. One could imagine devising a type scheme that would replace this combination of properties, but in fact Leo doesn't have such a scheme. In fact, types can be seen as a week form of **design properties**. Imo, these design constraints, rather than types, are the real basis of understand a program as complex as Leo. Design properties seem especially useful at **choke points**, places in the code that handle much of the work load. For key handling, the choke points are: - gui.setFilter - eventFilter - k.masterKeyHandler - k.masterCommand Let's look at each in turn: 1. gui.setFilter allows assertions to be made about *all* objects and widgets for which binding exist. 2. eventFilter calls k.masterKeyHandler for *all* key events. 3. k.masterKeyHandler calls k.getPaneBinding for *all* key events. 4. k.masterCommand dispatches *all* Leo commands, with the appropriate arguments. It's amusing to note that none of the above 4 statements involves types. In fairness, however, the types of the arguments passed to k.masterKeyHandler, k.masterCommand, and all the functions dispatched by k.masterCommand *do* matter. As a result of the recent work, I am looking for ways to enforce global design constraints. I'm not sure how much of this work will involve types in any way... 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
