[Fwd: Re: [ANN] Preference pragmas]

Here is a comments of Andreas. He compares our two different approaches
Cheers
Alain

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




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project