Bitten by MethodReference
Locked
 
|
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 Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/10/29 Stéphane Ducasse <[hidden email]>:
> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Bitten by MethodReference
|
|
>>
> > 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. Indeed. I have no idea. > 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. yes > 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. I imagine that we will have to clean that. It costs me a couple of hours looking for the wrong bug when copying classes..... grgrgrgrg Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Bitten by MethodReference
|
|
In reply to this post by Igor Stasenko
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. Adrian On Oct 31, 2009, at 13:59 , Igor Stasenko wrote: > 2009/10/29 Stéphane Ducasse <[hidden email]>: >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Bitten by MethodReference
|
|
for storing package information for method for example.
And this is not clear to me that method should know their selector so a compiled method could be a pure vm entity and a methodref its metaobject :) Stef On Oct 31, 2009, at 6:55 PM, Adrian Lienhard wrote: > 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. > > Adrian > > On Oct 31, 2009, at 13:59 , Igor Stasenko wrote: > >> 2009/10/29 Stéphane Ducasse <[hidden email]>: >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Adrian Lienhard
2009/10/31 Adrian Lienhard <[hidden email]>:
> 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 <[hidden email]>: >>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Bitten by MethodReference
|
|
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 <[hidden email]>: >> 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 <[hidden email]>: >>>> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |