2009/10/31 Adrian Lienhard <[email protected]>: > 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 <[email protected]>: >>> 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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
