Keep in mind that pragmas are operated on and do not have to
become message selectors themselves.

You can reduce the number of selector permutations if you 
do not use the pragma symbol as a single selector, but use
the first keyword part to detect the pragma and the
additional parts as separate parameter arguments.

> 
> 	<preference: 'Slider Value'
> 		category: 'Slider'
> 		description: 'The default slider value'
> 		type: #Number
> 		min: 0
> 		max: 100>


When you do a pragma search you would look for the pattern
'preference:*'

If you try to use multiple pragmas to set additional parameters
you may make it harder to use the pragmas in a different manner.
In VW sometimes multiple menu pragmas are used in one method
to make the menu command appear in multiple menus.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      traymond at craftedsmalltalk.com
<http://www.craftedsmalltalk.com>
===========================================================
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Andreas Raab
> Sent: Sunday, March 08, 2009 5:10 PM
> To: The general-purpose Squeak developers list
> Subject: [squeak-dev] Re: [ANN] Preference pragmas
> 
> Folks -
> 
> After the flurry of replies to something that was intended just to be a
> small goodie I decided to allow the situation to calm down a little then
> sit and think about what a good way to go forward is.
> 
> I think of all the things that were said, Travis comment was the most
> relevant as far as practical applicability is concerned. I certainly do
> see the problem of proliferation that he's raising (it has been a
> problem in other situations that I've been in). However, after having an
> extensive lunch discussion with Eliot on Friday about the use of
> VisualWorks menu pragmas and what went wrong with them, I think there
> are two options to address this problem and I am planning to use both:
> 
> 1) Restrain yourself. One of the problems with VW menu pragmas appears
> to be the complexity of menu specifications (which is understandable).
> However, for preferences handling I think it is fair to provide a
> solution that covers 98% of the common cases and give users that require
> the additional 2% to bind to the preferences implementation directly
> (this wouldn't be an option for the VW menu pragma problem since it is
> used differently than what we're talking about for preferences).
> 
> 2) Don't permutate selectors. It is natural for us to extend the
> selector if we need a variant or an additional argument since this is
> the way you do it in Smalltalk. However, with pragmas you can have
> additional pragmas that specify extra information that are not in the
> base pragma. For example, instead of having a variant:
> 
> 	<preference: 'Slider Value'
> 		category: 'Slider'
> 		description: 'The default slider value'
> 		type: #Number
> 		min: 0
> 		max: 100>
> 
> one can do this:
> 
> 	<preference: 'Slider Value'
> 		category: 'Slider'
> 		description: 'The default slider value'
> 		type: #Number>
> 	<preferenceRangeMin: 0 max: 100>
> 
> This leaves the base pragma intact while being able to specify "extended
> attributes" for cases that aren't covered.
> 
> Another insightful issue in the discussion with Eliot is that he pointed
> out that in his perspective pragmas are "executable" meaning that there
> should be a method that has the signature of the pragma and that handles
> whatever the pragma is supposed to describe. The obvious advantage here
> is that by using "senders of" you can find the users of a pragma and by
> looking at "implementors of" you can find the handlers for a pragma.
> 
> I fully agree with Eliot on this and will change the implementation such
> that there is a findable #preference:category:description:type: method.
> 
> This brings me to my conclusions: After all that's been said I'm more
> than ever in favor of having a simple, straightforward menu pragma which
> by design doesn't try to be everything for everybody. It should allow us
> to cover the basic cases that make up 98% of all preferences but no
> more. Consequently, I am proposing that the simple preferences
> implementation should handle the following types: Boolean, Numbers,
> Strings, Colors, Fonts, and choices (i.e, an element of a literal list)
> and no more.
> 
> This will cover all existing cases in Squeak today. I am at this point
> against proposing any additional attributes, but I will make a few
> proposals about how to handle specific issues:
> 
> 1) Ranges. Ranges should be handled by the accessor method. In other
> words, instead of specifying a range in the pragma you would implement this:
> 
> spyPriority
> 	<preference: 'Spy Priority'
> 		category: 'Debug'
> 		description: 'Sets the priority for MessageTally'
> 		type: #Number>
> 
> spyPriority: aNumber
> 	SpyPriority := aNumber truncated min: 79 max: 40.
> 
> This is a natural and straightforward guard that avoids complicating the
> preference specification.
> 
> 2) Nested Categories. Nested categories could be specified by using a
> period as delimiter, for example:
> 
> spyPriority
> 	<preference: 'Spy Priority'
> 		category: 'Debug.MessageTally'
> 		description: 'Sets the priority for MessageTally'
> 		type: #Number>
> 
> 3) Multiple Categories. Multiple categories can already be specified by
> putting in the pragma twice in its respective categories. An alternative
> to this could be to allow providing a literal array of categories, for
> example:
> 
> spyPriority
> 	<preference: 'Spy Priority'
> 		category: #('Debug' 'MessageTally')
> 		description: 'Sets the priority for MessageTally'
> 		type: #Number>
> 
> None of the latter two are implemented at this point, and I am not
> planning to implement them any time soon so let's not get hung up with a
> discussion of the particular benefits of either approach. They are here
> to show that some features could be easily added even within the
> restrained approach provided here.
> 
> Anything that cannot be handled in the simple pragma scope described
> here is by definition out of scope for the simple preference pragma. If
> you need more complexity, you will require a specific preference
> implementation such as Alain's.
> 
> Which brings me to my final comments here: I think that combining both
> approaches, a simple preference pragma with a more fully developed
> preference implementation is really the way forward since it allows us
> to rewrite all the current uses in a way that will be forward compatible
> with Alain's (or someone else's) implementation.
> 
> I will update my implementation to comply with the above rules ASAP.
> 
> Cheers,
>    - Andreas