Reflectivity: Links that de-install themselves (oneShot)
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
This is really beautiful :). Doru On Wed, Sep 16, 2015 at 10:52 AM, Marcus Denker <marcus.denker@inria.fr> 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
-- www.tudorgirba.com "Every thing has its own flow"
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
On 19 Sep 2015, at 01:10, stepharo <stepharo@free.fr> 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
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 <stepharo@free.fr> 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
On 20 Sep 2015, at 16:17, Marcus Denker <marcus.denker@inria.fr> wrote:
On 19 Sep 2015, at 01:10, stepharo <stepharo@free.fr> 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: https://pharo.fogbugz.com/f/cases/16654/test-for-optionOneShot-and-accessors... <https://pharo.fogbugz.com/f/cases/16654/test-for-optionOneShot-and-accessors...> Marcus
participants (3)
-
Marcus Denker -
stepharo -
Tudor Girba