[Pharo-project] CompiledMethod and MethodReference
I was playing with compiledMethod and MethodReference and it would be great if they could be more polymorphic: MethodReference>>methodClass ^ self actualClass I was also thinking that it would be nice to have the package associated with the MethodReference eg: (Character>>#escapeEntities) package -> PackageInfo-Base What do you think about that? Stef
I was playing with compiledMethod and MethodReference and it would be great if they could be more polymorphic:
MethodReference>>methodClass ^ self actualClass
It will probably not do any harm, but why should a MethodReference be polymorphic with a compiled method?
I was also thinking that it would be nice to have the package associated with the MethodReference eg:
(Character>>#escapeEntities) package
-> PackageInfo-Base
What do you think about that?
Good improvement +1 Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jun 15, 2009, at 3:12 PM, Alexandre Bergel wrote:
I was playing with compiledMethod and MethodReference and it would be great if they could be more polymorphic:
MethodReference>>methodClass ^ self actualClass
It will probably not do any harm, but why should a MethodReference be polymorphic with a compiled method?
like that we have a better system with less iskindof and methodClass vs. actualClass a MethodReference is a kind of wrapper for compiled method at the level of the tools so we would all gain having a good intersection between the two.
I was also thinking that it would be nice to have the package associated with the MethodReference eg:
(Character>>#escapeEntities) package
-> PackageInfo-Base
What do you think about that?
Good improvement +1
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I was playing with compiledMethod and MethodReference and it would be great if they could be more polymorphic:
MethodReference>>methodClass ^ self actualClass
It will probably not do any harm, but why should a MethodReference be polymorphic with a compiled method?
like that we have a better system with less iskindof and methodClass vs. actualClass a MethodReference is a kind of wrapper for compiled method at the level of the tools so we would all gain having a good intersection between the two.
yes, absolutely, good idea. Also useful: MethodReference>>selector ^self methodSymbol
I was also thinking that it would be nice to have the package associated with the MethodReference eg:
(Character>>#escapeEntities) package
-> PackageInfo-Base
What do you think about that?
yes, makes sense. But this would be CompiledMethod here, not MethodReference, IMO? David
I was also thinking that it would be nice to have the package associated with the MethodReference eg:
(Character>>#escapeEntities) package
-> PackageInfo-Base
What do you think about that?
yes, makes sense. But this would be CompiledMethod here, not MethodReference, IMO?
A CompiledMethod should be freed from any information about its location (methodClass and selector). Firstly, CompiledMethod are not only declared in classes. For example, you can have methods in Traits or in Layers (context-oriented programming). Secondly, classes, traits or layers have their own method dictionary associating CompiledMethods with selectors. Why can't we allow a method to be defined with different selectors in different entities ? Therefore, for me #>> should return a MethodReference containing the location informations (the container (class, trait, layer) + associated selector) and the actual wrapped CompiledMethod. I think compiled methods are too strongly dependent on the class system. Antoine
A CompiledMethod should be freed from any information about its location (methodClass and selector).
This is not doable. A compiled method should know its class, else you cannot get the super keyword. Moreover, the numerous tools make heavy use of reflection. Having information such as the selector speeds the whole thing up. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jun 15, 2009, at 4:42 PM, David Röthlisberger wrote:
I was playing with compiledMethod and MethodReference and it would be great if they could be more polymorphic:
MethodReference>>methodClass ^ self actualClass
It will probably not do any harm, but why should a MethodReference be polymorphic with a compiled method?
like that we have a better system with less iskindof and methodClass vs. actualClass a MethodReference is a kind of wrapper for compiled method at the level of the tools so we would all gain having a good intersection between the two.
yes, absolutely, good idea.
Also useful:
MethodReference>>selector ^self methodSymbol
I was also thinking that it would be nice to have the package associated with the MethodReference eg:
(Character>>#escapeEntities) package
-> PackageInfo-Base
What do you think about that?
yes, makes sense. But this would be CompiledMethod here, not MethodReference, IMO?
yes :) but we should do both :) and may be one day we will not need MethodReference :) Stef
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Alexandre Bergel -
Antoine Marot -
David Röthlisberger -
Stéphane Ducasse