Protocol redundancy

[LinqLover]

The current protocol for a Model that supports Autocompletion includes the following information:

• #selectedClassOrMetaClass
• CompletionController, specifying
  • #allowOverriding, which indicates whether we want to parse a method or plain code (or does it have any other purpose?)
  • #workspace
• Respecting Context-dependent suggestions #29, #completionContext

Almost always when I want to equip a model with a range of cool Squeak features - mainly DoIt & Co., Shout, and Autocompletion - I also need to provide the following details:

• For DoIt & Co., specify #doItReceiver (and respecting Context-dependent suggestions #29, #doItContext)
• For Shout, override #aboutToStyle: (or respecting ToolBuilder-Morphic-ct.228, alternatively #aboutToStyle:forMorph:), specifying
  • #selectedClassOrMetaClass:
  • #parseAMethod:
  • #workspace:
  • Respecting Tools-ct.853, #context:

Moreover, many classes already specify #selectedClassOrMetaClass for miscellaneous purposes.

---

I find there is some protocol duplication. When would a model want different types for DoIt, Shout and Autocompletion? I would welcome a simplification and unification of these protocols!

• As Shout & Autocompletion do not only have a similar semantic, but also use the same parser: Would it be an option to attach the configuration of Autocompletion to the configuration of Shout? You then would only need to overwrite #aboutToStyle:[forMorph:], unless special features like #completionAdditionals are required.
• Hypothetically: Are there any plans to integrate Autocompletion into Squeak? This could possibly simplify the integration into Squeak (as there are some conflicts with the old OCompletion at the moment) and allow you to solve possible design issues like this in a larger context. And it would make happy each Squeak user how did not discover this repo :-) On the other side, the comfort of using a git repo instead of a mailing list would fall away. Just some thoughts ...