Still a dependancy (unavoidable) on whatever preferenceManager points to...
Better than direct class reference, I agree. (c.f. UIManager delegation).

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


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.