[squeak-dev] [ANN] Preference pragmas

> Hi Alain -
>
> Alain Plantec wrote:
>>
>> With Pharo approach, your code depends on a unique small hierarchy of
>> classes exactly as it can depend on Collection one.
>
> To me there is a big difference: From my perspective all preferences code is
> UI code. Why? Because at the system level we use class variables and
> messages, not preferences. At the system level if you want to broadcast an
> event you use announcements or some other event system.
>
> The sole purposes of preferences is to expose certain system variables to
> the end-user. Consequently, preferences are part of the UI layer.

> Hi Andreas,
>
> Andreas Raab a écrit :
>> 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):
> ...
>> 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.

>
> On Mar 6, 2009, at 1:30 AM, Alain Plantec wrote:
>
>> Hi Andreas,
>>
>> Andreas Raab a écrit :
>>>
>>> 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):
>>
>> ...
>>>
>>> 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.
>
> <rest snipped>
>
> I've just been lurking, didn't even see the front of this thread. But when I
> saw the lengthy method tag (pragma) in the previous post, it caught my
> attention. And now, at least part of this discussion seems to be on how much
> meta data to put in the method tag.
>
> In my experience, you should use the strength of Smalltalk to build objects
> and send messages between them to the utmost here. You should use method
> tags (pragmas) to provide only enough information to help you discover
> *which* methods to send for a particular service.
>
> I wrote about what I see as a long running fiasco with the VisualWorks menu
> pragmas and how that "syntax" got completely out of control. And how we have
> moved beyond it.
>
> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944
>
> That was more than a year ago, and I still stand, more than ever, behind the
> assertions made there. Having simplified the menu pragmas down to the bare
> essentials of "method discovery" and put the actual code in, uh, code, has
> been great. I don't see a reason Squeak/Pharoa Preferences wouldn't benefit
> in the same way.
>
> Apologies if I misunderstood the jst of this thread and am off topic.
>

>
> On Mar 6, 2009, at 1:30 AM, Alain Plantec wrote:
>
>> Hi Andreas,
>>
>> Andreas Raab a écrit :
>>>
>>> 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):
>>
>> ...
>>>
>>> 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.
>
> <rest snipped>
>
> I've just been lurking, didn't even see the front of this thread. But when
> I
> saw the lengthy method tag (pragma) in the previous post, it caught my
> attention. And now, at least part of this discussion seems to be on how
> much
> meta data to put in the method tag.
>
> In my experience, you should use the strength of Smalltalk to build
> objects
> and send messages between them to the utmost here. You should use method
> tags (pragmas) to provide only enough information to help you discover
> *which* methods to send for a particular service.
>
> I wrote about what I see as a long running fiasco with the VisualWorks
> menu
> pragmas and how that "syntax" got completely out of control. And how we
> have
> moved beyond it.
>
> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944
>
> That was more than a year ago, and I still stand, more than ever, behind
> the
> assertions made there. Having simplified the menu pragmas down to the bare
> essentials of "method discovery" and put the actual code in, uh, code, has
> been great. I don't see a reason Squeak/Pharoa Preferences wouldn't
> benefit
> in the same way.
>
> Apologies if I misunderstood the jst of this thread and am off topic.
>

> Regards, Gary
>
> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Friday, March 06, 2009 7:25 PM
> Subject: Re: [squeak-dev] Re: [ANN] Preference pragmas
>
>
> - Show quoted text -
> 2009/3/6 Travis Griggs <[hidden email]>:
>>
>> On Mar 6, 2009, at 1:30 AM, Alain Plantec wrote:
>>
>>> Hi Andreas,
>>>
>>> Andreas Raab a écrit :
>>>>
>>>> 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):
>>>
>>> ...
>>>>
>>>> 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.
>>
>> <rest snipped>
>>
>> I've just been lurking, didn't even see the front of this thread. But when
>> I
>> saw the lengthy method tag (pragma) in the previous post, it caught my
>> attention. And now, at least part of this discussion seems to be on how
>> much
>> meta data to put in the method tag.
>>
>> In my experience, you should use the strength of Smalltalk to build
>> objects
>> and send messages between them to the utmost here. You should use method
>> tags (pragmas) to provide only enough information to help you discover
>> *which* methods to send for a particular service.
>>
>> I wrote about what I see as a long running fiasco with the VisualWorks
>> menu
>> pragmas and how that "syntax" got completely out of control. And how we
>> have
>> moved beyond it.
>>
>>
>> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944
>>
>> That was more than a year ago, and I still stand, more than ever, behind
>> the
>> assertions made there. Having simplified the menu pragmas down to the bare
>> essentials of "method discovery" and put the actual code in, uh, code, has
>> been great. I don't see a reason Squeak/Pharoa Preferences wouldn't
>> benefit
>> in the same way.
>>
>> Apologies if I misunderstood the jst of this thread and am off topic.
>>
>
> No, your post were strictly on topic.
> I read a blog post and now i think that the main argument against
> using declarative pragma syntax is:
>
> "Doing this, you lose all the benefits of having a real object that
> you can send real messages to. Which means you've avoided using
> Smalltalks halmark strength."
>
> And counter argument is:
>
> "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 , like
> PreferenceValue and so on.."
>
> Then how about compromise:
>
> gradientButtonLookPreference: preferenceManager
> <preference>
> | prefDeclaration |
> prefDeclaration := preferenceManager preferenceName: 'Gradient look for
> buttons'
>                     description: 'Gradient look for buttons'
>                     type: #Boolean
>                     default: false;
>                     getter: #gradientButtonLook setter: #gradientButtonLook:
> .
>
> ^ prefDeclaration foo bar zork.
>
>    .... etc...
>
> In the example above, i just wanted to illustrate , that there is no
> need to be dependent on global names, like PreferenceValue etc.
> We could define a protocol which can be used to declare a preference,
> and all methods with <preference> pragma should follow it.
> a preferenceManager can be anything, can use any classes what it needs
> to give user a way to define/change preferences.
> Still no direct dependency between code which declaring preference and
> preference management framework, except that it expects a
> preferenceManager to support a certain protocol.
>
>
>
>> --
>> Travis Griggs
>> Objologist
>> For every adage, there is an equal and contrary un-adage
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
>

>  prefDesc name: 'Gradient button look'
>  prefDesc description: 'blablabla'
>  ....
>  prefDesc unusualMessage: foo with: bar
>
>
> It is simple to put in prefDesc class, whatever it may be, the DNU
> handler which will simply ignore all unknown messages,
> and maybe note that it may be not fully/validly described:
>
> PredDescClass>>doesNotUnderstand: aMessage
>   self usingUnknownProtocol: true.
>  ^ self
>
> Dependency is unavoidable ( use a specific protocol to define preference)
> but unlike the pragmas, which statically defining preference , and
> obviously using another protocol for it,
> we sending a messages to a real object and hence could use the
> strengths of Smalltalk.
>
>> Regards, Gary
>>
>> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> Sent: Friday, March 06, 2009 7:25 PM
>> Subject: Re: [squeak-dev] Re: [ANN] Preference pragmas
>>
>>
>> - Show quoted text -
> - Show quoted text -
>> 2009/3/6 Travis Griggs <[hidden email]>:
>>>
>>> On Mar 6, 2009, at 1:30 AM, Alain Plantec wrote:
>>>
>>>> Hi Andreas,
>>>>
>>>> Andreas Raab a écrit :
>>>>>
>>>>> 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):
>>>>
>>>> ...
>>>>>
>>>>> 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.
>>>
>>> <rest snipped>
>>>
>>> I've just been lurking, didn't even see the front of this thread. But when
>>> I
>>> saw the lengthy method tag (pragma) in the previous post, it caught my
>>> attention. And now, at least part of this discussion seems to be on how
>>> much
>>> meta data to put in the method tag.
>>>
>>> In my experience, you should use the strength of Smalltalk to build
>>> objects
>>> and send messages between them to the utmost here. You should use method
>>> tags (pragmas) to provide only enough information to help you discover
>>> *which* methods to send for a particular service.
>>>
>>> I wrote about what I see as a long running fiasco with the VisualWorks
>>> menu
>>> pragmas and how that "syntax" got completely out of control. And how we
>>> have
>>> moved beyond it.
>>>
>>>
>>> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944
>>>
>>> That was more than a year ago, and I still stand, more than ever, behind
>>> the
>>> assertions made there. Having simplified the menu pragmas down to the bare
>>> essentials of "method discovery" and put the actual code in, uh, code, has
>>> been great. I don't see a reason Squeak/Pharoa Preferences wouldn't
>>> benefit
>>> in the same way.
>>>
>>> Apologies if I misunderstood the jst of this thread and am off topic.
>>>
>>
>> No, your post were strictly on topic.
>> I read a blog post and now i think that the main argument against
>> using declarative pragma syntax is:
>>
>> "Doing this, you lose all the benefits of having a real object that
>> you can send real messages to. Which means you've avoided using
>> Smalltalks halmark strength."
>>
>> And counter argument is:
>>
>> "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 , like
>> PreferenceValue and so on.."
>>
>> Then how about compromise:
>>
>> gradientButtonLookPreference: preferenceManager
>> <preference>
>> | prefDeclaration |
>> prefDeclaration := preferenceManager preferenceName: 'Gradient look for
>> buttons'
>>                     description: 'Gradient look for buttons'
>>                     type: #Boolean
>>                     default: false;
>>                     getter: #gradientButtonLook setter: #gradientButtonLook:
>> .
>>
>> ^ prefDeclaration foo bar zork.
>>
>>    .... etc...
>>
>> In the example above, i just wanted to illustrate , that there is no
>> need to be dependent on global names, like PreferenceValue etc.
>> We could define a protocol which can be used to declare a preference,
>> and all methods with <preference> pragma should follow it.
>> a preferenceManager can be anything, can use any classes what it needs
>> to give user a way to define/change preferences.
>> Still no direct dependency between code which declaring preference and
>> preference management framework, except that it expects a
>> preferenceManager to support a certain protocol.
>>
>>
>>
>>> --
>>> Travis Griggs
>>> Objologist
>>> For every adage, there is an equal and contrary un-adage
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> Regards, Gary
>
> ----- Original Message ----- From: "Igor Stasenko" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Friday, March 06, 2009 7:25 PM
> Subject: Re: [squeak-dev] Re: [ANN] Preference pragmas
>
>
> - Show quoted text -
> 2009/3/6 Travis Griggs <[hidden email]>:
>>
>> On Mar 6, 2009, at 1:30 AM, Alain Plantec wrote:
>>
>>> Hi Andreas,
>>>
>>> Andreas Raab a écrit :
>>>>
>>>> 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):
>>>
>>> ...
>>>>
>>>> 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.
>>
>> <rest snipped>
>>
>> I've just been lurking, didn't even see the front of this thread. But
>> when
>> I
>> saw the lengthy method tag (pragma) in the previous post, it caught my
>> attention. And now, at least part of this discussion seems to be on how
>> much
>> meta data to put in the method tag.
>>
>> In my experience, you should use the strength of Smalltalk to build
>> objects
>> and send messages between them to the utmost here. You should use method
>> tags (pragmas) to provide only enough information to help you discover
>> *which* methods to send for a particular service.
>>
>> I wrote about what I see as a long running fiasco with the VisualWorks
>> menu
>> pragmas and how that "syntax" got completely out of control. And how we
>> have
>> moved beyond it.
>>
>>
>> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Menu_Items_Are_Objects_Too&entry=3354355944
>>
>> That was more than a year ago, and I still stand, more than ever, behind
>> the
>> assertions made there. Having simplified the menu pragmas down to the
>> bare
>> essentials of "method discovery" and put the actual code in, uh, code,
>> has
>> been great. I don't see a reason Squeak/Pharoa Preferences wouldn't
>> benefit
>> in the same way.
>>
>> Apologies if I misunderstood the jst of this thread and am off topic.
>>
>
> No, your post were strictly on topic.
> I read a blog post and now i think that the main argument against
> using declarative pragma syntax is:
>
> "Doing this, you lose all the benefits of having a real object that
> you can send real messages to. Which means you've avoided using
> Smalltalks halmark strength."
>
> And counter argument is:
>
> "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 , like
> PreferenceValue and so on.."
>
> Then how about compromise:
>
> gradientButtonLookPreference: preferenceManager
> <preference>
> | prefDeclaration |
> prefDeclaration := preferenceManager preferenceName: 'Gradient look for
> buttons'
> description: 'Gradient look for buttons'
> type: #Boolean
> default: false;
> getter: #gradientButtonLook setter: #gradientButtonLook:
> .
>
> ^ prefDeclaration foo bar zork.
>
> .... etc...
>
> In the example above, i just wanted to illustrate , that there is no
> need to be dependent on global names, like PreferenceValue etc.
> We could define a protocol which can be used to declare a preference,
> and all methods with <preference> pragma should follow it.
> a preferenceManager can be anything, can use any classes what it needs
> to give user a way to define/change preferences.
> Still no direct dependency between code which declaring preference and
> preference management framework, except that it expects a
> preferenceManager to support a certain protocol.
>
>
>
>> --
>> Travis Griggs
>> Objologist
>> For every adage, there is an equal and contrary un-adage
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
>

>>> My approach differs in such that it is aimed at being discoverable
>>> without introducing any dependencies.
>> I don't think so, you are introducing a dependency on a particular
>> syntax wich is <preference: something: somethingelse: >
>> I think it is better to rely on classes and not to depend on a flat
>> syntax.
>
> There is no dependency on syntax. A dependency exists if some code
> requires some other code to be present in order to function correctly.
> In other words, if you load code that uses your preferences into some
> other image it will not function until your preference implementation
> is loaded. That is a dependency.

>
>>> 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 ]
>>>
>> You also need
>> defaultPollPeriod: aNumber
>>    DefaultPollPeriod := aNumber
> Actually, do me a favour and make a change that exposes
> defaultPollPeriod via your implementation. This will allow us to
> compare notes and also put the dependency discussion into context.

>
>> It allows  system level notification because #PreferenceValue>>value:
>> triggers a #PreferenceChanged events.
>
> Obviously, if you'd like notifications about something like it you
> would use, e.g.,
>
> MessageTally class>>defaultPollPeriod: aNumber
>
>   DefaultPollPeriod := aNumber.
>   self announce: (DefaultPollPeriodChanged value: aNumber).

>
> so it's simply a regular event that notifies listeners about the
> change if that is desired (and of course, if you'd want to present
> this as a preference event you could do that too).
>
>>> However, since this was discovered via pragmas, no dependency
>>> between Preferences and MessageTally has been created.
>> again, the dependency is on the syntax of the pragma
>
> There is no dependency on syntax. The FFI has a dependency on syntax
> as in ulong 'SomeMethod' (ulong long char*) etc. Tweak has a
> dependency on syntax, such as remote assignments as in anObject value
> := 42.
>
> Preference pragmas have no dependency on syntax. Preference pragmas
> mark up methods so that they can be discovered by a preference
> implementation.

>
>> ok but the pragma-only declaration is poor: only flat syntax which
>> allows only literals as parameters.
>> the consequence is that you can't deal with one-to-many or range
>> preference or something else you can discover later.
>
> Ah, but you can. That is a major advantage of it. For example,
> consider range:
>
> glyphContrast
>     <preference: 'Glyph contrast'
>         category: 'Freetype'
>         description: 'Change the contrast level for glyphs. This is an
> integer between 1 and 100. (the default value is 50)'
>         type: #Number
>         min: 1
>         max: 100>
>     ^GlyphContrast

>
> Simplicity rules. At the point where you start wanting to have complex
> UIs for setting preferences, I would offer the option to embed such
> UIs directly, along the lines of:
>
> uiTheme
>     <preference: 'UI Theme'
>         panelMorph: #uiThemeChooserMorph
>         description: 'The UI Theme'>
>
> The panelMorph would describe a selector that is called by the
> preference implementation to provide a custom preference panel. This
> allows for maximum flexibility without the need to complicate the
> implementation.
>
> However, this just emphasizes that all of this is UI code. All you do
> is providing instructions for the UI how to present things. Nothing
> wrong with it, but goes to the heart of why I think all of this is
> really UI code.

>
>> If you only make use of a poor preference declaration (I consider
>> preference pragma flat declaration as a poor flat textual declaration)
>> it can have bad effects on the quality of the code which is using
>> the preference.
>
> How so? The preference isn't even visible to code. Code only uses what
> code has ever used: Variables and Messages.
>
>> See how freetype hinting preference are currently handled.
>> You have 4 boolean preferences wheras following declaration better fits:
>
> Okay. How about this:
>
> hintingPreference
>     <preference: 'Hinting Preference'
>         category: 'FreeType'
>         description: 'How glyphs should be rendered'
>         type: #Choice
>         values: #(light medium heavy)>
>
>     ^HintingPreference
>
> hintingPreference: aSymbol
>     aSymbol = #light ifTrue:[
>         "set light hinting values"
>     ].
>     "..."

>
>> Thus, the declaration is more rich. As a consequence, also with the
>> help of the system level notification,
>> a client code can be much more simple and well designed.
>
> I'm not sure why your example would be simpler or better designed than
> what I am showing above. I mean my point here is that you provide the
> methods that are being required, that you actually write the code that
> other client code would use. And once you've done this you just tell
> the system that it also can present that as a preference.

>
>> The last point you maybe missed (which is maybe not so important) is
>> that what we are declaring is a tree of preferences.
>
> Yes. But again, extensibility is a major advantage of pragma
> preferences. See above.
>
>> ah, the real last point is the default value: in your point of view,
>> default values depend on value type.
>
> No! Absolutely not. From my point of view there is no "default" value
> (well, you could add this if you needed it but I think it's completely
> pointless). There is only the current value which is the value of some
> variable.

>
> [I will admit that my implementation is incomplete in this regard; it
> should not use the Preference's value but rather fetch the value
> straight from the source. I'll fix that eventually]
>
>> I can't agree with that point of view. It would mean, as an example,
>> that every boolean preferences have false, or true as the default.
>> The problem with non-literals then arises if you want to declare
>> default value with pragma...
>
> Once more, there is no "default". If one needed it it could be added
> (cf. extensibility above) but I don't see a need. A preference is some
> variable that has a value, no more.
>
>> ah, again. If your system relies on a <preference:truc:...> syntax.
>> What about evolution of the system ?
>
> And for a third time, there is no dependency, so there is no issue
> with evolution of the system. If you load code that has a preference
> pragma into a system that doesn't know what to do with it, it will
> just ignore it. Your code will continue to function without any
> modifications.

>
>> Gary Chambers quote: -------------------------
>>> The simple pragma approach I described would make it easier for the
>>> tools though since they wouldn't need a separate model (or hang onto
>>> the pragma) in order to work.
>>>
>>> Also, for user applications. Our ReportBuilder, for instance, also
>>> has an end-user ui for preferences local to itself. Having acccess
>>> to the default value/description withough having to find the pragma
>>> would be easier. (Just an example, the ReportBuilder actually uses
>>> xml config files for its prefs).
>> ------------------------- End of Gary quote
>
> That seems to be a very specific implementation request. I wouldn't
> base a framework decision on some report builder using xml config
> files for prefs ;-)

> spyPriority
> <preference: 'Spy Priority'
> category: 'Debug'
> description: 'Sets the priority for MessageTally'
> type: #Number>
>
> spyPriority: aNumber
> SpyPriority := aNumber truncated min: 79 max: 40.
>
> This is a natural and straightforward guard that avoids complicating the
> preference specification.
>

> Gary Chambers wrote:
>> The use of "extended" pragmas is interesting, although, to my mind it
>> doesn't address the problem/benefit of complex preference values
>> (non-literal).
>>
>> As for the value guard, good, but the ranges etc. are not exposed to
>> potential tools (would be nice to NOT be able to input 99, for instance).
>>
>> I think, at this stage, I still believe the "modelling of a preference"
>> approach more flexible.
>
> I agree with this statement. It is more flexible to model the preference
> explicitly. And I am not proposing to make the preference pragma achieve
> that level of flexibility. What I'm proposing is to keep the pragma as
> simple as possible, use it in the cases where it's useful and model the
> preference explicitly if more flexibility is required.
>
> This way, the dependency on a specific preference implementation will be
> greatly reduced and for many uses preferences can be added to low-level
> code without introducing a dependency on the implementation. Plus it makes
> shipping preferences between implementations reasonably easy; much of the
> code that would otherwise be incompatible between Pharo and Squeak (and
> beyond, for example VW) can be compatible.
>
> Cheers,
>   - Andreas
>

>
> Indeed, I see the point you are making.
>
> I just have a "feeling" that making this as restrictive will mean we'll
> be having the same discussion soon again!
> Always tricky to get any decisions made without a solution that
> satisfies all viewpoints...
>
> What I will say in favour of David's work is that it is extensible and,
> like your approach, deals with the localisation vs. general kackness
> that is the current situation.
>
> I could live with "extension methods" on a Preference class, I think
> (probably)... just  a bit nasty with it dynamically compiling code etc.
>
> We should all discuss some more, perhaps, to get the best solution we
> can, given that this is quite fundamental (Squeakers are *used* to
> having choice...).
>
> Regards, Gary
>
> ----- Original Message ----- From: "Andreas Raab" <[hidden email]>
> To: "The general-purpose Squeak developers list"
> <[hidden email]>
> Sent: Monday, March 09, 2009 1:40 AM
> Subject: [squeak-dev] Re: [ANN] Preference pragmas
>
>
>> Gary Chambers wrote:
>>> The use of "extended" pragmas is interesting, although, to my mind it
>>> doesn't address the problem/benefit of complex preference values
>>> (non-literal).
>>>
>>> As for the value guard, good, but the ranges etc. are not exposed to
>>> potential tools (would be nice to NOT be able to input 99, for
>>> instance).
>>>
>>> I think, at this stage, I still believe the "modelling of a
>>> preference" approach more flexible.
>>
>> I agree with this statement. It is more flexible to model the
>> preference explicitly. And I am not proposing to make the preference
>> pragma achieve that level of flexibility. What I'm proposing is to
>> keep the pragma as simple as possible, use it in the cases where it's
>> useful and model the preference explicitly if more flexibility is
>> required.
>>
>> This way, the dependency on a specific preference implementation will
>> be greatly reduced and for many uses preferences can be added to
>> low-level code without introducing a dependency on the implementation.
>> Plus it makes shipping preferences between implementations reasonably
>> easy; much of the code that would otherwise be incompatible between
>> Pharo and Squeak (and beyond, for example VW) can be compatible.
>>
>> Cheers,
>>   - Andreas
>>
>
>
>

> Hi Gary -
>
> Let me throw in one additional thought: I'm not sure how one would deal
> with migration in Alain's case (I don't know David's work; I'm assuming
> you misspoke, but if not please point me to it). One of the issues is that
> there are currently some 694 (!) references to Preferences in a 3.10.2
> image. There will be more in external code.
>
> One of the advantages of using a pragma for the simple cases is that we
> can start the migration today, without having sorted out all the details
> for the next-gen preferences implementation. People who want their code to
> work both in Squeak and Pharo can start doing this as soon as have a
> reasonable implementation for both (which I am willing to provide). I also
> don't expect the migration to be quick as there will be discussion where
> certain preferences should live etc.
>
> A drop-dead conversion of saying "the day we load the new preferences
> implementation all old code will be broken" just won't work. So having a
> way that we know will be forward-compatible strikes me as absolutely
> necessary for any migration process. This is what I meant when I was
> saying that I think having something that abstracts from the preference
> implementation is absolutely necessary before we can consider adopting an
> alternative.
>
> Cheers,
>   - Andreas
>
> Gary Chambers wrote:
>>
>> Indeed, I see the point you are making.
>>
>> I just have a "feeling" that making this as restrictive will mean we'll
>> be having the same discussion soon again!
>> Always tricky to get any decisions made without a solution that satisfies
>> all viewpoints...
>>
>> What I will say in favour of David's work is that it is extensible and,
>> like your approach, deals with the localisation vs. general kackness that
>> is the current situation.
>>
>> I could live with "extension methods" on a Preference class, I think
>> (probably)... just  a bit nasty with it dynamically compiling code etc.
>>
>> We should all discuss some more, perhaps, to get the best solution we
>> can, given that this is quite fundamental (Squeakers are *used* to having
>> choice...).
>>
>> Regards, Gary
>>
>> ----- Original Message ----- From: "Andreas Raab" <[hidden email]>
>> To: "The general-purpose Squeak developers list"
>> <[hidden email]>
>> Sent: Monday, March 09, 2009 1:40 AM
>> Subject: [squeak-dev] Re: [ANN] Preference pragmas
>>
>>
>>> Gary Chambers wrote:
>>>> The use of "extended" pragmas is interesting, although, to my mind it
>>>> doesn't address the problem/benefit of complex preference values
>>>> (non-literal).
>>>>
>>>> As for the value guard, good, but the ranges etc. are not exposed to
>>>> potential tools (would be nice to NOT be able to input 99, for
>>>> instance).
>>>>
>>>> I think, at this stage, I still believe the "modelling of a preference"
>>>> approach more flexible.
>>>
>>> I agree with this statement. It is more flexible to model the preference
>>> explicitly. And I am not proposing to make the preference pragma achieve
>>> that level of flexibility. What I'm proposing is to keep the pragma as
>>> simple as possible, use it in the cases where it's useful and model the
>>> preference explicitly if more flexibility is required.
>>>
>>> This way, the dependency on a specific preference implementation will be
>>> greatly reduced and for many uses preferences can be added to low-level
>>> code without introducing a dependency on the implementation. Plus it
>>> makes shipping preferences between implementations reasonably easy; much
>>> of the code that would otherwise be incompatible between Pharo and
>>> Squeak (and beyond, for example VW) can be compatible.
>>>
>>> Cheers,
>>>   - Andreas
>>>
>>
>>
>>
>
>

> -----Original Message-----
> From: [hidden email] [mailto:squeak-dev-
> [hidden email]] On Behalf Of Andreas Raab
> Sent: Sunday, March 08, 2009 5:10 PM
> To: The general-purpose Squeak developers list
> Subject: [squeak-dev] Re: [ANN] Preference pragmas
>
> Folks -
>
> After the flurry of replies to something that was intended just to be a
> small goodie I decided to allow the situation to calm down a little then
> sit and think about what a good way to go forward is.
>
> I think of all the things that were said, Travis comment was the most
> relevant as far as practical applicability is concerned. I certainly do
> see the problem of proliferation that he's raising (it has been a
> problem in other situations that I've been in). However, after having an
> extensive lunch discussion with Eliot on Friday about the use of
> VisualWorks menu pragmas and what went wrong with them, I think there
> are two options to address this problem and I am planning to use both:
>
> 1) Restrain yourself. One of the problems with VW menu pragmas appears
> to be the complexity of menu specifications (which is understandable).
> However, for preferences handling I think it is fair to provide a
> solution that covers 98% of the common cases and give users that require
> the additional 2% to bind to the preferences implementation directly
> (this wouldn't be an option for the VW menu pragma problem since it is
> used differently than what we're talking about for preferences).
>
> 2) Don't permutate selectors. It is natural for us to extend the
> selector if we need a variant or an additional argument since this is
> the way you do it in Smalltalk. However, with pragmas you can have
> additional pragmas that specify extra information that are not in the
> base pragma. For example, instead of having a variant:
>
> <preference: 'Slider Value'
> category: 'Slider'
> description: 'The default slider value'
> type: #Number
> min: 0
> max: 100>
>
> one can do this:
>
> <preference: 'Slider Value'
> category: 'Slider'
> description: 'The default slider value'
> type: #Number>
> <preferenceRangeMin: 0 max: 100>
>
> This leaves the base pragma intact while being able to specify "extended
> attributes" for cases that aren't covered.
>
> Another insightful issue in the discussion with Eliot is that he pointed
> out that in his perspective pragmas are "executable" meaning that there
> should be a method that has the signature of the pragma and that handles
> whatever the pragma is supposed to describe. The obvious advantage here
> is that by using "senders of" you can find the users of a pragma and by
> looking at "implementors of" you can find the handlers for a pragma.
>
> I fully agree with Eliot on this and will change the implementation such
> that there is a findable #preference:category:description:type: method.
>
> This brings me to my conclusions: After all that's been said I'm more
> than ever in favor of having a simple, straightforward menu pragma which
> by design doesn't try to be everything for everybody. It should allow us
> to cover the basic cases that make up 98% of all preferences but no
> more. Consequently, I am proposing that the simple preferences
> implementation should handle the following types: Boolean, Numbers,
> Strings, Colors, Fonts, and choices (i.e, an element of a literal list)
> and no more.
>
> This will cover all existing cases in Squeak today. I am at this point
> against proposing any additional attributes, but I will make a few
> proposals about how to handle specific issues:
>
> 1) Ranges. Ranges should be handled by the accessor method. In other
> words, instead of specifying a range in the pragma you would implement this:
>
> spyPriority
> <preference: 'Spy Priority'
> category: 'Debug'
> description: 'Sets the priority for MessageTally'
> type: #Number>
>
> spyPriority: aNumber
> SpyPriority := aNumber truncated min: 79 max: 40.
>
> This is a natural and straightforward guard that avoids complicating the
> preference specification.
>
> 2) Nested Categories. Nested categories could be specified by using a
> period as delimiter, for example:
>
> spyPriority
> <preference: 'Spy Priority'
> category: 'Debug.MessageTally'
> description: 'Sets the priority for MessageTally'
> type: #Number>
>
> 3) Multiple Categories. Multiple categories can already be specified by
> putting in the pragma twice in its respective categories. An alternative
> to this could be to allow providing a literal array of categories, for
> example:
>
> spyPriority
> <preference: 'Spy Priority'
> category: #('Debug' 'MessageTally')
> description: 'Sets the priority for MessageTally'
> type: #Number>
>
> None of the latter two are implemented at this point, and I am not
> planning to implement them any time soon so let's not get hung up with a
> discussion of the particular benefits of either approach. They are here
> to show that some features could be easily added even within the
> restrained approach provided here.
>
> Anything that cannot be handled in the simple pragma scope described
> here is by definition out of scope for the simple preference pragma. If
> you need more complexity, you will require a specific preference
> implementation such as Alain's.
>
> Which brings me to my final comments here: I think that combining both
> approaches, a simple preference pragma with a more fully developed
> preference implementation is really the way forward since it allows us
> to rewrite all the current uses in a way that will be forward compatible
> with Alain's (or someone else's) implementation.
>
> I will update my implementation to comply with the above rules ASAP.
>
> Cheers,
>    - Andreas