2009/3/6 Gary Chambers <gazzaguru2 at btinternet.com>:
> Still a dependancy (unavoidable) on whatever preferenceManager points to...
> Better than direct class reference, I agree. (c.f. UIManager delegation).
>

A more revised variant is:

describeGradientButtonPreferende: prefDesc

  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" <siguctua at gmail.com>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Friday, March 06, 2009 7:25 PM
> Subject: Re: [squeak-dev] Re: [ANN] Preference pragmas
>
>
> - Show quoted text -
> 2009/3/6 Travis Griggs <travisgriggs at gmail.com>:
>>
>> 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.