Latest completion update: simpler, better
We have just updated the test code completion version in Pharo 8 with the latest changes. This is a big development, because finally, enabled with the help of TestCompletionController, the completion set as the default in Pharo is fully up-to-date with our progress in this project.
Much better and entirely independent of the old NECompletion (main functionality-wise, we’ve kept the old UI implementation), it doesn’t just use the AST instead of the old SHParser, but also does all the type determination and completion related actions entirely on its own.
The current status of the new implementation so far is more or less even with the old completion (it wins in some ways and loses in others). For example, it is faster, but as of now it doesn’t prioritise the results in the way that we need it to (i.e. for temps). However, in terms of code refactoring, by getting rid of the unnecessary parts or replacing them with much simpler architecture, we have managed to make the implementation both much easier to understand and extend.
Code refactoring improvements
We implemented one CompletionModel class instead NECModel and its three subclasses — Typed, Untyped, and Empty. In our model the specific typing behaviour is determined on another level, mainly in MatchedNodeProducer, and thus we could easily get rid of the distinction on the model level.
Another important thing in terms of simplifying the architecture was replacing the NECEntry and it’s 7 subclasses with a single CompletionEntry class. Similarly to the model, the typing in our completion is done with the help of the TypingVisitor which removes the need to determine the specifics on the Entry level. Instead of 9 Entry-related classes and 48 methods defined or redefined among them, we now only have one class with 5 methods, and it works (of course, we are still in the process of testing all the cases).
Performance improvements
In the version of our code completion that we had as of late June, we had some problems with determining types and assigning correct labels to the completion suggestions. In the last couple of weeks, we have fixed the label from ‘todo’ to a specific label that names the type, if we can infer it (for example, for a number it will give ‘SmallInteger’, etc). As for typing, having moved to completely relying on our own AST-based typing we were faced with a few DNUs (‘does not understand’ errors) and incorrect typing, so with adding a handful more of visiting/updating methods and better specifying the behaviour in standalone RB node completionToken methods, we have managed to take care of more or less all the completion possibilities where we know the type, and just giving generalised results or no results at all, depending on necessity, for things the type of which we don’t know.
One of the bigger problems this last week, once we started relying only on the single CompletionEntry class was giving completion for method selectors, as the speed was a major concern. With using cached version of all the method selectors in Pharo (which we got through getting the Symbol selectorTable), we were able to make our completion much faster and efficient.
As has been mentioned, we have tried our best to test it and make sure it is usable, but of course there still might be bugs around. We know of a couple of odd cases, that we are currently working to fix, but if you find anything else that isn’t already on the issue tracker here, feel free to add it yourself or contact me on twitter, discord, or the mailing list.
Hope this overview is helpful and that the newest version of completion does its job well. Looking forward to your feedback.
-M
