[squeak-dev] Re: [ANN] Preference pragmas

Travis Griggs travisgriggs at gmail.com
Fri Mar 6 18:17:11 UTC 2009


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.

--
Travis Griggs
Objologist
For every adage, there is an equal and contrary un-adage




More information about the Squeak-dev mailing list