Integrating the RegisteringFileList
danielv at netvision.net.il
danielv at netvision.net.il
Sat Jan 19 12:39:30 UTC 2002
Here's a survey of a refactoring Stef's sent to the list, in the hope
this will lead to accepting this change into the base image, or someone
else doing it better. Also it's a pretty good example of the sort of
that clean up dependencies and make Squeak more modular.
I haven't yet surveyed everything, but it's not that complicated, so
here're my initial findings:
1. Stef's purpose is to remove mentions to other classes from the
FileList, which basically know every file-format Squeak can do anything
to and every tool to do it. These dependencies currently make the system
much less modular. These tools should be optional, but not having them
in the system currently breaks the FileList.
2. The mechanism is pretty simple.
* When a class for a new tool is filed in, it's initialize method tells
FileList that it too can handle files.
* When a FileList menu is raised, it asks each file handling class what
services it can provide for this file ending.
* Each file handler returns a collection of ServiceEntries. Currently,
* An SSE knows a reciever, a selector and a label.
* When the user clicks the menu item with the label in the SSE, the
right message is sent to the appropriate reciever. Voila.
* When the class is removed, it is deregistered.
3. What do the changes look like?
* FileList has some new class side functionality to handle the registry.
* Around 20 classes now implement #fileReaderServicesForSuffix: and
#lastActionBeforeRemoveFromSystem and the interface methods to apply the
service to a file. The initialize is modified to register the class.
* SSE is added, and a few other classes (menus, for example) are changed
for compatibility. I haven't yet read the other classes.
4. What's missing -
* The "all services, whether relevant or not" menu item unimplemented
under the new scheme.
* Not all the wild references are removed from FileList, though many
are. Many methods in FileList have flag:
5. What's needs doing to add this to the image?
* This should be split into more managable chunks, separating the
simple, idiomatic changes I listed from the other changes to the system.
Other changes need to be reviewed in detail.
* Every tool needs to be tested by a human.
* The dead "all services" option should be removed.
* SSE is a butt-ugly name which should be eradicated ;-)
6. Is it worth it? I think it is. Its pretty minimal and simple. Some
parts can be reused - we could use SSE's (ugh) to modularize the Browser
next, for example.
I'll tease the two chunks of code apart along the lines I mentioned one
of these days, for your inspecting pleasure. I hope people will then
help testing that Stef didn't break anything, and maybe complete the
I love the "browse code" functionality, and specifically the "remove
existing" portion... those are great.
More information about the Squeak-dev