On Mon, Mar 07, 2016 at 03:13:10PM -0800, marcel.taeumel wrote:
> It's actuallly really simple:
> 
> term := #swapMouseButtonsChanged.
> senders := OrderedCollection new.
> 
> SystemNavigation default allObjectsDo: [:ea |
> 	1 to: ea class instSize do: [:i | |val|
> 		val := ea instVarAt: i.
> 		val isSymbol ifTrue: [
> 			val = term ifTrue: [senders add: ea]]]].
> 
> senders explore.
> 
> On my laptop, it benches to '11.6 per second. 85.9 milliseconds per run.'
> 
> Should we add this to trunk? We could filter out method additions or method
> references to produce cleaner results. The "Senders" shortcut might just
> spawn an additional explorer with the resulting objects. Fairly easy.
> 
> Best,
> Marcel
>

I do like this idea. But just to keep in in context, I want to remind us of
the original problem that we were trying to address.

IIRC, the original problem was that we had a preference with a #changeSelector
that had been initialized to something other than the default pattern of
#somethingChanged. Specifically, for that particular preference, the selector
was #installMouseDecodeTable rather than #swapMouseButtonsChanged.

So later on, someone made some improvements to the preferences mechanism
that somehow caused that preference to be re-initualized, so that its
#changeSelector was now the default selector #swapMouseButtonsChanged.
That did not work because there had never been an implementation of
EventSensor>>swapMouseButtonsChanged.

Marcel figured this out and added the missing implementation:

	EventSensor>>swapMouseButtonsChanged
		self installMouseDecodeTable.

So at this point, we know of exactly one preference that caused a problem
because the historical #changeSelector did not match the default pattern.

Are there other preference that would lead to the same kind of confusion?
After adding an accessor for #changeSelector, I find that in my image:

	((Preference allSubInstances select: [ :e | ( e changeSelector notNil
		and: [ ( '*Changed' match: e changeSelector ) not ] )
			and: [ #value ~= e changeSelector ] ] ) 
				collect: [:e | e changeSelector] ) asSet asArray.
	==> #(#serviceUpdate #doAutomaticLayoutOfFlapsIfAppropriate #universalTilesSettingToggled #changesInPreferences #classicTilesSettingToggled)

So without looking into the details, I would say that there are maybe five
of these selectors that could possibly cause a problem. If one or more of
them is a concern, then I would expect that the missing #somethingChanged.
implementation could be provided, exactly as was done for
EventSensor>>swapMouseButtonsChanged.

Looking to the future, I would expect that as new preferences are added,
they would naturally follow the convention of using #somethingChanged as
the changed selector.

So do we need to engineer a solution to this problem? Maybe not. It might
be better to just find any existing preferences that might still have a
problem, fix them, and move forward with the assumption that any new
preferences will follow the established #somethingChanged convention.

Dave