On Sun, May 2, 2010 at 10:32 AM, Chris Cunnington <
smalltalktelevision at gmail.com> wrote:

> Editor class>>blinkingCursor
> 	<preference: 'Blinking Text Cursor'
> 		category: 'Morphic'
> 		description: 'When true, the text cursor will blink.'
> 		type: #Boolean>
> 	^ BlinkingCursor ifNil: [ true ]
>
>
> 1. compile method (i.e. x := Editor class compiledMethodAt:
> #blinkingCursor)
>
> 2. compiled method is sent #pramas message to see if it has any (i.e. x
> pragmas)
>
> 3. it does, so they are executed as a message send before the rest of the
> method is executed (i.e. ^ BlinkingCursor ifNil: [ true ])
>
> 4. this changes the context of the system in anticipation of the code in
> the method
>
> For example, Editor class #blinkingCursor will set a Preference in the
> system before the rest of the method executes
>
> Problem: How does the System know the receiver the pragma message is
> supposed to be sent to? Usually, we have a class, we send a message, and
> return an error if the class doesn't have that selector.
>
> Here, we only have a method, no specified class. The pragma messages are
> all unique, they only exist in one class in the system. Perhaps the system
> identifies the receiver by the uniqueness of the message, and then sends
> it.
>
> Only Preferences is going to have preference:category:description:type:
>

> Therefore, pragma messages are not polymorphic, because they are only ever
> defined in a single class (i.e. #primitive: or #primitive:error: in Parser)
>

In this case but not necessarily.  I can imagine a polymorphic
implementation of documentaion pragmas for example.


>
> A package is installed. It doesn't register its needs. The system does so
> by sending the #pragmas message to compiled methods of the package to be
> present a list of pragmas. It looks at the returned list, makes a decision,
> and executes one (or all) of the pragmas as a message to a receiver. Thus,
> the System context is changed and the package can then proceed.
>
> What is it I'm not getting here? I still don't understand how a receiver
> presents itself to receive the selector in the pragma. Any help would be
> greatly appreciated.
>

Some event causes some object to go search for methods containing specific
pragmas and to apply those pragmas to some given object.  In the above case
the implementor is Preferences class and the receiver is Preferences and, as
Bert says, the event casing the trawl is Preferences class>>prefEvent:.  See
Preferences class>>registerForEvents: for the hookup that sends prefEvent:
whenever a method is added or removed.

So let's revisit your list:

0. an object (typically a class) that wants to respond to
pragmas^H^H^H^H^H^H^H method tags uses some means for being notified of
method additions and removals.

1. compile method (i.e. x := Editor class compiledMethodAt:
#blinkingCursor)

2. the class (and possibly others uninterested in this specific method tag)
is notified of the method addition via an event

3. compiled method is sent #pramas message to see if it has any (i.e. x
pragmas) by the class which (in this case) performs the method tag to obtain
the preference and stores it in the perferences dictionary under the
method's selector.



There are some implications for package loading such as Monticello.  It is
convenient if e.g. a Monticello load, which is essentially a bulk compile,
class hierarchy edit and method remove step, batch the events until after
the entire package is loaded/updated.  For example, a menu method tag that
specifies an entry in a menu for a particular selector might include an icon
name for the menu entry and depending on package load order the icon method
may not have been compiled yet if the method tag is processed immediately
the method is compiled.  If notifications are deferred until the entire
package has been processed then there's no problem.  At least that was our
experience with VisualWorks.


best
Eliot


> Chris
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100502/9a01802b/attachment.htm