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.