Hi Squeakers, few news about the Safarà development status.
Portability
Safarà now runs on Pharo
With few changes, the main features of Safarà runs on Pharo, which, here on, will be the main platform of development. The only issue, I will tackle, in maintaining Safarà working both on Squeak and on Pharo is about the Parser class as I previously used the Parser2 class for editing Smalltalk code.
Stability
As we need to refactor some internal part of Safarà to improve the speed, I worked a lot on adding more unit tests. They are really useful to check that refactorings do not introduce new bugs and to find with the profiler the bottlenecks of the system.
We got the 92% of code coverage of the Safarà-Core category by running all the tests in Safarà-Core-Tests (98 tests). The remaining 8% is mainly about methods of abstract classes (question: is there a way to make Test Runner Coverage analysis ignore an abstract class?) and some basic accessors. This part can be improved further as some tests do not test some behaviors at boundaries, but, actually, they already give me a good warranty when refactoring.
Code Quality
A big effort has been also put in refactoring the code (both of the implementation and the tests) to make the code critics tool "happy". At the moment we have only two problems, related to the main object SAEditor which have too many variables (14) and too many methods (64).
I tried to group variables in new objects: a MarkManager (4 of them), an UIManager (3 of them), CommandManager (2 of them), but I was not satisfied with this solution, too much complicated.
Furthermore, objects that should use the SAEditor accessors with statements like
editor markManager cursorsAtPoint size = 1 fails the Demeter Law.
I do not know if I should mind about the problem of having too many methods, as the SAEditor object should be the only object exposed to the GUI. The GUI communicates with the model through the Command pattern, and a lot of other communications are implemented with Announcements, but queries about the editor internal state is mainly done with traditional methods sending.
Thus, the number of methods for cursor/range/marker querying is big. For the same reason stated above I do not find useful to use an other solution.
In facts, we can have a clear design just by partitioning methods into categories.
Next steps
Here on, we can work on improving performance of Safarà. The problems resides mainly in the Morphic part.
For the model part, the task is not so difficult as I individuated, thanks to the Profiler, the bottlenecks.
For the UI part, I started also to look at Sophie, who use a complete different drawing scheme. It should not be difficult to rewrite the SASafaraMorph in the same way. More in the next posts.
Happy Hacking
