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

Andreas Raab andreas.raab at gmx.de
Sun Mar 8 21:10:27 UTC 2009


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



More information about the Squeak-dev mailing list