On Thu, Apr 29, 2010 at 4:53 AM, Henrik Johansen <
[email protected]> wrote:

> On Apr 29, 2010, at 1:44 29PM, Alain Plantec wrote:
>
> > Henrik Johansen a écrit :
> >> On Apr 29, 2010, at 11:30 06AM, Stéphane Ducasse wrote:
> >>
> >> It's not a question of one vs. the other, really.
> >> The cs doesn't change the Settings implementation, it simply adds
> support for also discovering settings defined in the pragma style used by
> Squeak.
> >> The downside is you'd have two ways to define settings.
> >> The upside is the
> > the upside is ... :)
> > well, I will have a look at the cs.
> > I would prefer that this changes do not introduce any
> > overwriting so that it can be loaded separately as a compatibility
> package.
> > so, i will investigate the changes needed for the settingbrowser.
> > is that ok like that ?
> > Cheers
> > Alain
>
> It needs a way to register new valid preference pragmas, and setting
> generators for such pragmas.
> May I suggest... using pragmas? ;P
>

This ids the way it works (and has worked for nearly 10 years) in
VisualWorks.  On the class side one can declare the pragmas a class supports
using pragmas.  One uses pragmas to avoid having one method that defines all
pragmas for a class, which would create a potential conflict between
packages of the kind that pragmas help avoid.  When the compiler encounters
a pragma it searches the class side looking for the pragmas that are "in
scope" at the moment.  The argument to the pragma: pragma is a symbol
stating which side of the class the pragma is valid (why they don't support
#both or #(class instance) I don't know).  Here are some examples:

AboutVisualWorksPage class methods for private
pagePragma

<pragmas: #class>
^#(pageOrder:)

systemPragma

<pragmas: #class>
^#(systemInformation:)

BlockClosure class methods for private
exceptionPragmas
<pragmas: #instance>

^#(#exception:)

StandardSystemController class methods for resources
 menuMethodPragmas
<pragmas: #instance>
<pragmas: #class>

^Menu pragmas


With this approach a package can add its own method annotations to a
hierarchy without conflicting with any other package.  Here's the VW code
that fetches the pragmas understood by a class:


Metaclass methods for compiling
recognizedMethodPragmas

^self soleInstance recognizedMethodPragmas: #class

Class methods for compiling
recognizedMethodPragmas

^self recognizedMethodPragmas: #instance

requiredRecognizedPragmas

^#(#pragmas: #primitive: #primitive:errorCode:)

recognizedMethodPragmas: type
"The 'type' argument may be either #class or #instance"

| list beh |
list := IdentitySet withAll: self requiredRecognizedPragmas.
beh := self class.
[beh isMeta] whileTrue:
[beh selectorsAndMethodsDo: [:sel :meth | | pragmas |
pragmas := meth attributeMessages.
pragmas == nil ifFalse:
[pragmas do: [:msg |
(msg selector = #pragmas:
and: [msg arguments first = type])
ifTrue: [list addAll: (beh soleInstance perform: sel)]]]].
beh := beh superclass].
^list

Simple, but fabulously meta.  Thank Steve Dahl for this idea.

Cheers,
> Henry
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to