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