Implementing MethodWrappers in Smalltalk

> 1) For a generic approach to method wrappers, which of those two ways would
> you use ?   should I care about notifying, adding to localSelectors, etc?
> Or at is just temporal, I don't care ?
> which are the pros and cons you see with each alternative ?

I used #at:put: because we put-back the identical compiled methods as
fast as possible, even while the tests are running.

Triggering
notifications while running might also cause undesired side effects.
Also note that code doing reflection (iterating over pragmas,
literals, ...) might break if you are not super careful.

> 2) Do you think it make sense to the package  ObjectsAsMethodsWrap  in
> PharoCore as a "library" to create lightweight proxies ? It is just 4
> classes and it would be cool to change TestCoverage to that implementation.
> Then, you only don't have the library, but also some real examples. Of
> course, this can be done if we eleiminate the 30% of slowleness.

I guess it is slower because it is very generic and does block activations.

> so...what do you think ?

There are also MethodWrappers from the RB engine that come with an
integration into OB.

I wouldn't include the extra package, after all the implementation is
pretty simple and also very specific. For a different use-case the
implementation would probably look completely different. Check the
mailing list, we had some discussions and did various iterations back
when this was integrated.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Mariano,

I worked on a similar problem for a new code profiler. Spy is a framework for easily performing program execution analysis.
A short tutorial, screenshots, and some examples are available on:
http://www.moosetechnology.org/tools/Spy

If you're working in that direction, I would be delighted to collaborate.

Cheers,
Alexandre

On 22 Mar 2010, at 12:51, Mariano Martinez Peck wrote:

Hi folks. I was reading the PBE chapter about reflection where it talks a little about Method Wrappers. Then, I took a look at TestCoverage implementation.

After that, I took a look at http://www.squeaksource.com/ObjectsAsMethodsWrap

The main difference between both approaches are:

TestCoverage
- Just extends from ProtoObject, implement doesNotUnderstand:   ,  run: aSelector with: anArray in: aReceiver    , etc
- To install and uninstall the wrappers uses methodDictionary  at: xxx  put: yyy
- Just for test coverage.

ObjectAsMethodWrapper
- Is more generic, support pre and post closures, and you can subclass and create you own wrapper
- To install and uninstall the wrappers it uses Class >> addSelector: self selector withMethod: self

So...what I did ?? I created a TestCoverage but creating a subclass of ObjectAsMethodWrapper called TestCoverageMethodWrapper  which just implements a 1 or 2 methods. I mean, I reused the generic ObjectAsMethodWrapper.  It seems to work ok.

I did some test running TestCoverage with both implementation and it seems mine (TestCoverageMethodWrapper) is 30% much slower than the original.
Trying to understand why, I think it is because the original one uses just methodDictionary  at: xxx  put: yyy
but mine uses Class >> addSelector: self selector withMethod: self.
In this last method, there are all the notifications, add to localSelectors...etc

Now...I have two questions:

1) For a generic approach to method wrappers, which of those two ways would you use ?   should I care about notifying, adding to localSelectors, etc?   Or at is just temporal, I don't care ?
which are the pros and cons you see with each alternative ?

2) Do you think it make sense to the package  ObjectsAsMethodsWrap  in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness.


so...what do you think ?

Cheers

Mariano

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project