Currently the roles of the main classes (controller, context, menu and models) are pretty mixed into each other. They should however all perform just one role, these should be:

Controller Responsible for directing user input, to open/close the menu and to provide the menu with the appropriate model. Currently the controller is Smalltalk-specific, there are even subclasses for browsers and workspaces, that provide functionality that should probably belong to the context.

Current sins:

allowOverriding, #completionAdditionals, keeps a permanent reference to the context

Context The context should be responsible for detecting in what context Autocompletion was opened. Is there a receiver? What class is it? etc. Therefore this should be the first Smalltalk-specific part of the system, not the controller. The context should then be the first part that the Textfield-Model has controller over, basically deciding whether it is a Smalltalk-Textfield or something else. This would make it possible to implement #23 The context should therefore also be the one responsible for checking whether it is parsing a method, not the controller.

Possible sin: Contains a reference to the model, not necessarily a problem, but who knows

Model The Model is responsible for collecting all the entries, storing and filtering them There should be Smalltalk-specific models as well as general purpose ones.

Current issue: Pretty slow, otherwise the models code is pretty solid.

Menu The menu is responsible for displaying the model data. It should be as smalltalk-agnostic as possible.

Current sins: Keeps a permanent reference to the context which it uses to access the model instead of communicating with the model directly. Refactoring needed to remove the context from the model

LeonMatthes / Autocompletion

System Architecture rework #28

allowOverriding, #completionAdditionals, keeps a permanent reference to the context