[Reflectivity] more link options and enforcing link options per Class
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: https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt... <https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt...> 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
On 03 Oct 2015, at 14:41, MARCUS.DENKER@INRIA.FR 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:
https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt... <https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt...>
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: https://pharo.fogbugz.com/f/cases/16715/options-defined-by-classes-or-method... <https://pharo.fogbugz.com/f/cases/16715/options-defined-by-classes-or-method...> (some caching maybe later to speed up options parsing in the code generator, but for now it is important that it works correctly) Marcus
On 03 Oct 2015, at 2:41 , marcus.denker@inria.fr 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:
https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt... <https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt...>
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
On 05 Oct 2015, at 11:51, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On 03 Oct 2015, at 2:41 , marcus.denker@inria.fr <mailto:marcus.denker@inria.fr> 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:
https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt... <https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt...>
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
+ 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:
https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-opt...
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
participants (4)
-
Henrik Johansen -
Marcus Denker -
marcus.denker＠inria.fr
-
stepharo