The Trunk: System-tpr.1048.mcz

tim Rowledge uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-tpr.1048.mcz

==================== Summary ====================

Name: System-tpr.1048
Author: tpr
Time: 6 January 2019, 5:40:30.923283 pm
UUID: bac3c975-3c4b-441c-a8b2-3bb950f50631
Ancestors: System-pre.1047

Start to clean up theFileServices list of registered classes; CornerGripMorph really shouldn't be there.
By initialising the registry and rebuilding it we solve that small issue.
I'll assume that the initialize method will get run when loading this patch.

=============== Diff against System-pre.1047 ===============

Item was changed:
  ----- Method: FileServices class>>initialize (in category 'accessing') -----
  initialize
  "FileServices initialize"
+ FileReaderRegistry := nil.
  Smalltalk allClassesDo:[:aClass|
  (aClass class includesSelector: #fileReaderServicesForFile:suffix:)
  ifTrue:[self registerFileReader: aClass]].!

> On 2019-01-07, at 12:50 PM, Chris Cunningham <[hidden email]> wrote:
>
> So, this removed these clasese from the collection:
>   ChangeSorter
>   CornerGripMorph
>   MCMcdReader
>   MCMcmReader
>   MCMczReader

The CornerGripMorph was a cause of the bug that resulted in me keeping an old email tagged as something to work on, so that needed to go. I'm not sure about the MCM* entries to be honest; after all the code intended to create the registry is very explicit about avoiding inherited messages.

Is that mechanism the best one for building a registry? Explicitly cutting out inherited messages cuts both ways - making it that you don't add something just because it inherits from Object but also making it so that subclasses have to be explicitly fudged. Either way requires implementors to be fully aware of the issues, which in turn means that there needs to be some decent documentation of expectations in a place where one is likely to look.

>
> It also seems to have added this class to the list
>   DummyToolWorkingWithFileList

I *think* that would be appropriate since it seems to be testing the registration.

>
> I'm not sure if we should be worried, but thought I'd mention it.

Thanks for taking the time.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
No single raindrop believes it is to blame for the flood

Registering file service providers is even more fun than I thought -

>
> Is that mechanism the best one for building a registry? Explicitly cutting out inherited messages cuts both ways - making it that you don't add something just because it inherits from Object but also making it so that subclasses have to be explicitly fudged. Either way requires implementors to be fully aware of the issues, which in turn means that there needs to be some decent documentation of expectations in a place where one is likely to look.

It turns out that aside from the bulk registering aspect of
FileServices class>>#initialize
        "FileServices initialize"
        FileReaderRegistry := nil.
        Smalltalk allClassesDo:[:aClass|
                (aClass class includesSelector: #fileReaderServicesForFile:suffix:)
                        ifTrue:[self registerFileReader: aClass]].

... there are a bunch of classes that explicitly register themselves in their class initialize methods.

The oddities here are -
ChangeSorter (no implementation of #fileReaderServicesForFile:suffix:)
ChangesOrganizer (only *un*loaded?)
MessageNames (ditto)

I'd be interested in any info people can recall about why those might be that way. I'd be inclined to drop the specific registering in the various class #initialize methods. And I have a bunch of methods to commit where it seems best to replace fileList register..... with FileServices register..... but good grief did it involve splattering across a lot of packages.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
On Doc: http://www.poppyfields.net/filks/00281.html