Student proposal by Maurice Rabb
Over Squeak's 10+ year history, it has grown into a big ball of mud. As such, many attempts to make both incremental and radical improvements to the system have been thwarted by improperly tight couplings and dependencies. Many fundamental system classes and methods have been patched and tweaked by so many different authors, it is difficult for anyone but a Squeak expert to understand how they work. Since no one is "in charge," there are many methods in the system that are no longer in use or have otherwise been deprecated. In short, many core methods and classes are in dire need of refactoring. However, many developers have been loath to make changes or accept such changes to the core given the potentially serious consequences. Towards ensuring safety and confidence in this area, this project will demand comprehensive tests and documentation. The key target areas for refactoring in order of priority are:
1) Separate "chunking" methods from PositionableStream class into a separate ChunkSourceCodeStream class.
The abstract class PositionableStream is improperly cluttered by methods that are only relevant to the specifics of reading and writing source code. Furthermore, this interweaving of concerns prevents the easy implementation of other source code formats. I have been working on this as part of my work on the new VersionsBrowser. The new VersionsBrowser uses the cleanly coded ChunkSourceCodeStream, but current does nothing to deal with the junk and complications present in PositionableStream (and its subclasses).
2) Clean up the FileDirectory hierarchy and dependent classes.
In recent years some wonderful file management packages have been developed in Rio and FileMan. (A comparison is here.) While it would be ideal if the current file management classes were replaced by one of them, this cannot yet reliably be done. The current hierarchy needs to be cleaned up to a minimum degree so that it can be understood well enough for adequate tests to be written. Excellent test coverage of the current file management framework is necessary to ensure that a new file management framework can be substituted. Note: Keith Hodgesproposed replacing FileDirectory with Rio for last year's GSoC.
3) Remove implementation dependency of MethodDictionary from impacting the rest of the Set class hierarchy.
Many interesting refactorings of the Set hierarchy have been prevented by the VM's absolute requirements of the i-var configuration and slot probing algorithm of MethodDictionary. The restrictions on the implementation of MethodDictionary improperly impact the implementation strategies of other Set classes.
Are there other areas that would be more appropriate for me to refactor in the context of GSoC?
