Hi -

To get back to the original question, Michael Rueger wrote:
> Looking at your version I see you made some slightly different design 
> choices than in the design that has been in design discussion and worked 
> on in the last couple of weeks on the Pharo list.
> 
> Can you elaborate what motivated the different design? Meaning what 
> parts of the Pharo version could be made better?

Now that I've looked at Alain's code I can make a clearer statement 
about it. I was misled a little at first by the similarities in the 
pragma spec but the philosophy behind both implementations is actually 
fairly different.

Alain's implementation of preferences is an improvement on the current 
preference system but it is effectively replacing one set of 
dependencies with a different set of dependencies. Where previously 
Preferences would be registered and stored via Preferences 
addPreference:... in Alain's approach preferences get created via (the 
old version):

gradientButtonLook
	<preference: 'Gradient look for buttons' type: #Boolean set: 
#gradientButtonLook: defaultValue: true description: 'Gradient look for 
buttons'>
	^ GradientButtonLook
		ifNil: [GradientButtonLook := PreferenceValue
						value: true
						location: self
						selector: #gradientButtonLook]

or, with the latest:

gradientButtonLook
	<preference>
	^ GradientButtonLook
		ifNil: [GradientButtonLook := PreferenceValue
						name: 'Gradient look for buttons'
						description: 'Gradient look for buttons'
						parent: #uiPreferenceNode
						type: #Boolean
						default: false]

In other words, a dependency (to either PreferenceNode, PreferenceValue, 
RangePreferenceValue, MultiplePreferenceValue etc) is created and stored 
client-side.

My approach differs in such that it is aimed at being discoverable 
without introducing any dependencies. To illustrate, please load the 
latest (updated) version via:

Installer mantis bug: 7306 fix: 'PreferencePragmas.2.cs'.
Preferences registerForEvents.

And then do the following. Go into class MessageTally (to stay on-topic 
;-) and change the method #defaultPollPeriod to read:

defaultPollPeriod
	"Answer the number of milliseconds between interrupts for spyOn: and 
friends.
	This should be faster for faster machines."
	<preference: 'Default Poll Period'
		category: 'Profiling'
		description: 'The default poll period (msecs) MessageTally uses'
		type: #Number>
	^DefaultPollPeriod ifNil: [ DefaultPollPeriod _ 1 ]

(yes, the spec has changed a tiny bit; I like Alain's 'description' 
terminology better) Accept the method and open a preference browser. 
Voila! There is a brand new "Profiling" category which allows you to set 
MessageTally's default poll period. No further changes required.

However, since this was discovered via pragmas, no dependency between 
Preferences and MessageTally has been created. You can remove or replace 
the preferences implementation in the image without any side effects 
whatsoever on MessageTally or its code. A different preference 
implementation can discover the same preference and present it 
accordingly. This allows adding preferences wherever is convenient 
without needlessly introducing dependencies on a particular preference 
implementation or UI.

In Alain's version this would not be possible without actually changing 
code since it is directly coupled to a particular preference class and API.

Bottom line: I think my approach is a necessity before Alain's 
preference implementation can be usefully deployed. It allows us to 
define preferences without introducing dependencies to specific 
implementations, while allowing different implementations to discover 
the same preferences.

I hope this makes the conceptual difference clear.

Cheers,
   - Andreas