Reflectivity: Links that de-install themselves (oneShot)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Reflectivity: Links that de-install themselves (oneShot)

Marcus Denker-4
Hi,

This is just a one-liner to add to the framework, but that makes it even more fun: One-Shot links.

A link now can have the #optionOneShot, which means that it will de-install itself when activated for
the first time:

link := MetaLink new
                metaObject: self;
                options: #(optionOneShot);
                selector: #tagExec.

The full test looks like this:

testLinkOneShot
        | sendNode link |
        sendNode := (ReflectivityExamples>>#exampleMethod) sendNodes first.
        link := MetaLink new
                metaObject: self;
                options: #(optionOneShot);
                selector: #tagExec.
        sendNode link: link.
        self assert: sendNode hasMetalink.
        self assert: tag isNil.
        self assert: (ReflectivityExamples new exampleMethod = 5).
        self assert: (tag = #yes).
        self deny: sendNode hasMetalink.
        tag := nil.
        self assert: (ReflectivityExamples new exampleMethod = 5).
        self assert: tag isNil.


https://pharo.fogbugz.com/f/cases/16581/one-shot-links

Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Reflectivity: Links that de-install themselves (oneShot)

Tudor Girba-2
This is really beautiful :).

Doru

On Wed, Sep 16, 2015 at 10:52 AM, Marcus Denker <[hidden email]> wrote:
Hi,

This is just a one-liner to add to the framework, but that makes it even more fun: One-Shot links.

A link now can have the #optionOneShot, which means that it will de-install itself when activated for
the first time:

link := MetaLink new
                metaObject: self;
                options: #(optionOneShot);
                selector: #tagExec.

The full test looks like this:

testLinkOneShot
        | sendNode link |
        sendNode := (ReflectivityExamples>>#exampleMethod) sendNodes first.
        link := MetaLink new
                metaObject: self;
                options: #(optionOneShot);
                selector: #tagExec.
        sendNode link: link.
        self assert: sendNode hasMetalink.
        self assert: tag isNil.
        self assert: (ReflectivityExamples new exampleMethod = 5).
        self assert: (tag = #yes).
        self deny: sendNode hasMetalink.
        tag := nil.
        self assert: (ReflectivityExamples new exampleMethod = 5).
        self assert: tag isNil.


https://pharo.fogbugz.com/f/cases/16581/one-shot-links

Marcus



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: Reflectivity: Links that de-install themselves (oneShot)

stepharo
In reply to this post by Marcus Denker-4
Marcus I have a API design question

when you offer

options: #(optionOneShot);

versus

optionOneShot

Do you do a perform of the arrays selectors?
What is the benefit of options:
STef


Le 16/9/15 08:52, Marcus Denker a écrit :

> Hi,
>
> This is just a one-liner to add to the framework, but that makes it even more fun: One-Shot links.
>
> A link now can have the #optionOneShot, which means that it will de-install itself when activated for
> the first time:
>
> link := MetaLink new
> metaObject: self;
> options: #(optionOneShot);
> selector: #tagExec.
>
> The full test looks like this:
>
> testLinkOneShot
> | sendNode link |
> sendNode := (ReflectivityExamples>>#exampleMethod) sendNodes first.
> link := MetaLink new
> metaObject: self;
> options: #(optionOneShot);
> selector: #tagExec.
> sendNode link: link.
> self assert: sendNode hasMetalink.
> self assert: tag isNil.
> self assert: (ReflectivityExamples new exampleMethod = 5).
> self assert: (tag = #yes).
> self deny: sendNode hasMetalink.
> tag := nil.
> self assert: (ReflectivityExamples new exampleMethod = 5).
> self assert: tag isNil.
>
>
> https://pharo.fogbugz.com/f/cases/16581/one-shot-links
>
> Marcus
>


Reply | Threaded
Open this post in threaded view
|

Re: Reflectivity: Links that de-install themselves (oneShot)

Marcus Denker-4

> On 19 Sep 2015, at 01:10, stepharo <[hidden email]> wrote:
>
> Marcus I have a API design question
>
> when you offer
>
> options: #(optionOneShot);
>
> versus
>
> optionOneShot
>
> Do you do a perform of the arrays selectors?
> What is the benefit of options:

I needed a mechanism for flags (stored not each in an ivar, as they normally
not active). As we have this mechanism in Opal already, I decided to use the
same pattern.
As in Opal, for all the pre-defined options we should not rely on perform: but
have explicit #optionOneShot getter/setter methods. I will add those later..

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: Reflectivity: Links that de-install themselves (oneShot)

stepharo
Tx this is I think a good idea (adding the setter)

Le 20/9/15 14:17, Marcus Denker a écrit :

>> On 19 Sep 2015, at 01:10, stepharo <[hidden email]> wrote:
>>
>> Marcus I have a API design question
>>
>> when you offer
>>
>> options: #(optionOneShot);
>>
>> versus
>>
>> optionOneShot
>>
>> Do you do a perform of the arrays selectors?
>> What is the benefit of options:
> I needed a mechanism for flags (stored not each in an ivar, as they normally
> not active). As we have this mechanism in Opal already, I decided to use the
> same pattern.
> As in Opal, for all the pre-defined options we should not rely on perform: but
> have explicit #optionOneShot getter/setter methods. I will add those later..
>
> Marcus
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Reflectivity: Links that de-install themselves (oneShot)

Marcus Denker-4
In reply to this post by Marcus Denker-4

On 20 Sep 2015, at 16:17, Marcus Denker <[hidden email]> wrote:


On 19 Sep 2015, at 01:10, stepharo <[hidden email]> wrote:

Marcus I have a API design question

when you offer

options: #(optionOneShot);

versus

optionOneShot

Do you do a perform of the arrays selectors?
What is the benefit of options:

I needed a mechanism for flags (stored not each in an ivar, as they normally
not active). As we have this mechanism in Opal already, I decided to use the
same pattern.
As in Opal, for all the pre-defined options we should not rely on perform: but
have explicit #optionOneShot getter/setter methods. I will add those later..


DONE:



Marcus