Smalltalk › Pharo › Pharo Smalltalk Developers

[Reflectivity] more link options and enforcing link options per Class

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 5 messages Options
Marcus Denker-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

[Reflectivity] more link options and enforcing link options per Class

Marcus Denker-4
Hi,

The latest image now has some more options for meta links. The complete list is listed in the #defaultOptions method of
MetaLink class:

defaultOptions
^ #(
+ optionInlineMetaObject            "meta object is inlined by default."
+ optionInlineCondtion              "condition is inlined by default.”  (ups, typo, will fix)
- optionCompileOnLinkInstallation   "generate compiledMethod on link installation"
- optionOneShot                     "remove link after first activation"
- optionMetalevel                   "force level: 0 for the link"
- optionDisabledLink                "links are active by default"
)

Some of the options make only sense because after this issue will be integrated:


we will have a mechanism that classes can enforce options for all links installed in them. This is done by adding
a method on the instance or class side like this:

metaLinkOptions
^{
#exampleMethodWithMetaLinkOptionsViaClass -> #( + optionCompileOnLinkInstallation)
}

This allows e.g. a class to turn off links for one method or enforce using meta-level awareness.
(for now the options are overridden when installing a link, I will move this into the code generator
to have a real overlay semantics as a next step). 

Marcus
Marcus Denker-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Reflectivity] more link options and enforcing link options per Class

Marcus Denker-4

On 03 Oct 2015, at 14:41, [hidden email] wrote:

Hi,

The latest image now has some more options for meta links. The complete list is listed in the #defaultOptions method of
MetaLink class:

defaultOptions
^ #(
+ optionInlineMetaObject            "meta object is inlined by default."
+ optionInlineCondtion              "condition is inlined by default.”  (ups, typo, will fix)
- optionCompileOnLinkInstallation   "generate compiledMethod on link installation"
- optionOneShot                     "remove link after first activation"
- optionMetalevel                   "force level: 0 for the link"
- optionDisabledLink                "links are active by default"
)

Some of the options make only sense because after this issue will be integrated:


we will have a mechanism that classes can enforce options for all links installed in them. This is done by adding
a method on the instance or class side like this:

metaLinkOptions
^{
#exampleMethodWithMetaLinkOptionsViaClass -> #( + optionCompileOnLinkInstallation)
}

This allows e.g. a class to turn off links for one method or enforce using meta-level awareness.
(for now the options are overridden when installing a link, I will move this into the code generator
to have a real overlay semantics as a next step). 


Done:


(some caching maybe later to speed up options parsing in the code generator, but for now it is important that it works 
correctly)


Marcus
Henrik Sperre Johansen
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Reflectivity] more link options and enforcing link options per Class

Henrik Sperre Johansen
In reply to this post by Marcus Denker-4

On 03 Oct 2015, at 2:41 , [hidden email] wrote:

Hi,

The latest image now has some more options for meta links. The complete list is listed in the #defaultOptions method of
MetaLink class:

defaultOptions
^ #(
+ optionInlineMetaObject            "meta object is inlined by default."
+ optionInlineCondtion              "condition is inlined by default.”  (ups, typo, will fix)
- optionCompileOnLinkInstallation   "generate compiledMethod on link installation"
- optionOneShot                     "remove link after first activation"
- optionMetalevel                   "force level: 0 for the link"
- optionDisabledLink                "links are active by default"
)

Some of the options make only sense because after this issue will be integrated:


we will have a mechanism that classes can enforce options for all links installed in them. This is done by adding
a method on the instance or class side like this:

metaLinkOptions
^{
#exampleMethodWithMetaLinkOptionsViaClass -> #( + optionCompileOnLinkInstallation)
}

This allows e.g. a class to turn off links for one method or enforce using meta-level awareness.
(for now the options are overridden when installing a link, I will move this into the code generator
to have a real overlay semantics as a next step). 

Marcus

Why the aversion to classes?
Personally, I'd much prefer a MetaLinkOptions class with boolean instvars, and a class comment...

Would work much better with the tools we have (finding users, etc.) and a class enforcing method such as:

overrideMetaLinkOptions: options

^options 
oneShot: false; 
yourself 

Cheers,
Henry

signature.asc (859 bytes) Download Attachment
Marcus Denker-4
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Reflectivity] more link options and enforcing link options per Class

Marcus Denker-4

On 05 Oct 2015, at 11:51, Henrik Johansen <[hidden email]> wrote:


On 03 Oct 2015, at 2:41 , [hidden email] wrote:

Hi,

The latest image now has some more options for meta links. The complete list is listed in the #defaultOptions method of
MetaLink class:

defaultOptions
^ #(
+ optionInlineMetaObject            "meta object is inlined by default."
+ optionInlineCondtion              "condition is inlined by default.”  (ups, typo, will fix)
- optionCompileOnLinkInstallation   "generate compiledMethod on link installation"
- optionOneShot                     "remove link after first activation"
- optionMetalevel                   "force level: 0 for the link"
- optionDisabledLink                "links are active by default"
)

Some of the options make only sense because after this issue will be integrated:


we will have a mechanism that classes can enforce options for all links installed in them. This is done by adding
a method on the instance or class side like this:

metaLinkOptions
^{
#exampleMethodWithMetaLinkOptionsViaClass -> #( + optionCompileOnLinkInstallation)
}

This allows e.g. a class to turn off links for one method or enforce using meta-level awareness.
(for now the options are overridden when installing a link, I will move this into the code generator
to have a real overlay semantics as a next step). 

Marcus

Why the aversion to classes?
Personally, I'd much prefer a MetaLinkOptions class with boolean instvars, and a class comment...

Would work much better with the tools we have (finding users, etc.) and a class enforcing method such as:

overrideMetaLinkOptions: options

^options 
oneShot: false; 
yourself 


Yes.. the current way starts to be too complex… could be a good next step.

Marcus
stepharo
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: [Reflectivity] more link options and enforcing link options per Class

stepharo
+ 1
Symbols and strings and arrays are dead limited objects. Not even zomby objects. No behavior no fun.

The latest image now has some more options for meta links. The complete list is listed in the #defaultOptions method of
MetaLink class:

defaultOptions
^ #(
+ optionInlineMetaObject            "meta object is inlined by default."
+ optionInlineCondtion              "condition is inlined by default.”  (ups, typo, will fix)
- optionCompileOnLinkInstallation   "generate compiledMethod on link installation"
- optionOneShot                     "remove link after first activation"
- optionMetalevel                   "force level: 0 for the link"
- optionDisabledLink                "links are active by default"
)

Some of the options make only sense because after this issue will be integrated:


we will have a mechanism that classes can enforce options for all links installed in them. This is done by adding
a method on the instance or class side like this:

metaLinkOptions
^{
#exampleMethodWithMetaLinkOptionsViaClass -> #( + optionCompileOnLinkInstallation)
}

This allows e.g. a class to turn off links for one method or enforce using meta-level awareness.
(for now the options are overridden when installing a link, I will move this into the code generator
to have a real overlay semantics as a next step). 

Marcus

Why the aversion to classes?
Personally, I'd much prefer a MetaLinkOptions class with boolean instvars, and a class comment...

Would work much better with the tools we have (finding users, etc.) and a class enforcing method such as:

overrideMetaLinkOptions: options

^options 
oneShot: false; 
yourself 


Yes.. the current way starts to be too complex… could be a good next step.

Marcus
Free forum by Nabble Edit this page