2009/3/6 Igor Stasenko <siguctua at gmail.com>:
> 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
>
<preference>  "forgot it - should be here :)"

>  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 -
> - 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.
>



-- 
Best regards,
Igor Stasenko AKA sig.