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; tim at rowledge.org; http://www.rowledge.org/tim
On Doc: http://www.poppyfields.net/filks/00281.html