this is why in 1.0 I started to make sure that we could have CM and MR polymorphic at least to access information: methodClass selector Stef On Oct 31, 2009, at 10:17 PM, Igor Stasenko wrote:
2009/10/31 Adrian Lienhard <adi@netstyle.ch>:
I think that a main reason for using MethodReference was to be able to capture the class in which a method is installed and the method's selector. Before method properties were introduced, a method did not know its class and selector and hence all classes had to be searched to find this out (the method was named #who returning an array with the class and selector ;)).
I don't see any reason why MethodReference would still be useful as you can just reference a CompiledMethod directly.
The MethodReference abstraction, useful for tools, which don't need to go deep into CompiledMethod's details and just need to present a source code. With careful implementation, we can use same tools for browsing methods installed in system, as well as MC packages or files on disk, or remote object memory. Without such abstraction, tools will be limited only for presenting currently existing classes & methods installed in system.
So generally, it is good thing. But in current form it having shortcomings, which need to be fixed.
Adrian
On Oct 31, 2009, at 13:59 , Igor Stasenko wrote:
2009/10/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi
just to share a ugly design point with MethodReference
MethodReference are created using
MethodReference class: aClass symbol: aSymbol
however they store the class ***name***
and after when you query the class using either actualClass or methodClass you get the class that is in Smalltalk.
So if like me you copied the class then you will get another version of your class even if this is the right one you use to create the MethodReference....
One of these days we will have to check that
Yes, i wondering myself, what is the point to reference the methods in such style. The way, how actual class & its method get resolved makes it impossible to reference a method in arbitrary class object, especially one which is not installed into system dictionary.
I think its lacking additional form of indirection, which should be an environment object who is responsible for delivering the method's source code along with resolving the class by its name. Without such indirection, i see no point in having a MethodReference per se, because you can always do the same thing by yourself , i.e. (Smalltalk at: #SomeClass) methodDict at: #someSelector. Without that, i see no point why i would want to use it, because it always points to same thing, no matter where i using the MethodReference.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project