> On 05 Oct 2015, at 11:51, Henrik Johansen <[email protected]>
> wrote:
>
>
>> On 03 Oct 2015, at 2:41 , [email protected]
>> <mailto:[email protected]> 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-options-metaLinkOptions
>>
>> <https://pharo.fogbugz.com/f/cases/16695/allow-classes-to-force-meta-link-options-metaLinkOptions>
>>
>> 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
