CompiledMethod and MethodReference

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

CompiledMethod and MethodReference

Stéphane Ducasse
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: CompiledMethod and MethodReference

Alexandre Bergel
> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: CompiledMethod and MethodReference

Stéphane Ducasse

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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: CompiledMethod and MethodReference

David Röthlisberger-2

>>> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: CompiledMethod and MethodReference

Antoine Marot
>>>> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: CompiledMethod and MethodReference

Alexandre Bergel
> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: CompiledMethod and MethodReference

Stéphane Ducasse
In reply to this post by David Röthlisberger-2

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
> [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