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 <[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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
