Smalltalk › Squeak › Squeak - Dev

Pragma comprehension assistance, please

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Chris Cunnington

Pragma comprehension assistance, please

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)

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.

Chris

Bert Freudenberg

Re: Pragma comprehension assistance, please

On 02.05.2010, at 19:32, Chris Cunnington 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)

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.

Chris

These are not message sends but only tags. They are not "executed". There is no receiver.

The compiler puts them into the compiled method. Other code retrieves it - e.g. by sending #pragmas.

- Bert -

Bert Freudenberg

Re: Pragma comprehension assistance, please

On 02.05.2010, at 19:42, Bert Freudenberg wrote:

On 02.05.2010, at 19:32, Chris Cunnington 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)

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.

Chris
These are not message sends but only tags. They are not "executed". There is no receiver.

The compiler puts them into the compiled method. Other code retrieves it - e.g. by sending #pragmas.

- Bert -

In the case of preferences, the method accessing the pragmas is #prefEvent:.

- Bert -

Eliot Miranda-2

Re: Pragma comprehension assistance, please

In reply to this post by Chris Cunnington

On Sun, May 2, 2010 at 10:32 AM, Chris Cunnington <[hidden email]> 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