[Pharo-project] Traits depending on RIng
Hi guys. We were discussing in http://code.google.com/p/pharo/issues/detail?id=5748 The thing is that Traits are depenending on Ring. And I don't really like that. If you do a simple #addToComposition: you end up calling Ring. The problematic method is: TraitDescription >> #collectMethodsFor: aSelector into: methodDescription (self includesSelector: aSelector) ifTrue: [ methodDescription addLocatedMethod: ( RGMethodDefinition realClass: self selector: aSelector)] which uses RGMethodDefinition. Previously (before Ring) it was using LocatedMethod (which was removed) collectMethodsFor: aSelector into: methodDescription (self includesSelector: aSelector) ifTrue: [ methodDescription addLocatedMethod: ( LocatedMethod location: self selector: aSelector)] I attach a PharoDebug.log with a halt in #collectMethodsFor:into: so that you can see all the stack. This is the reason why FuelPackageLoader depends on Ring, just for the traits when we do the #addToComposition:. So...what do we do? we just accept the depedency? cheers -- Mariano http://marianopeck.wordpress.com
here is the log On Fri, May 4, 2012 at 11:28 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys. We were discussing in http://code.google.com/p/pharo/issues/detail?id=5748 The thing is that Traits are depenending on Ring. And I don't really like that. If you do a simple #addToComposition: you end up calling Ring.
The problematic method is:
TraitDescription >> #collectMethodsFor: aSelector into: methodDescription
(self includesSelector: aSelector) ifTrue: [ methodDescription addLocatedMethod: ( RGMethodDefinition realClass: self selector: aSelector)]
which uses RGMethodDefinition.
Previously (before Ring) it was using LocatedMethod (which was removed)
collectMethodsFor: aSelector into: methodDescription (self includesSelector: aSelector) ifTrue: [ methodDescription addLocatedMethod: ( LocatedMethod location: self selector: aSelector)]
I attach a PharoDebug.log with a halt in #collectMethodsFor:into: so that you can see all the stack.
This is the reason why FuelPackageLoader depends on Ring, just for the traits when we do the #addToComposition:.
So...what do we do? we just accept the depedency?
cheers
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
On Fri, May 4, 2012 at 11:28 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi guys. We were discussing in http://code.google.com/p/pharo/issues/detail?id=5748 The thing is that Traits are depenending on Ring. And I don't really like that. If you do a simple #addToComposition: you end up calling Ring.
The problematic method is:
TraitDescription >> #collectMethodsFor: aSelector into: methodDescription
(self includesSelector: aSelector) ifTrue: [ methodDescription addLocatedMethod: ( RGMethodDefinition realClass: self selector: aSelector)]
which uses RGMethodDefinition.
Previously (before Ring) it was using LocatedMethod (which was removed)
collectMethodsFor: aSelector into: methodDescription (self includesSelector: aSelector) ifTrue: [ methodDescription addLocatedMethod: ( LocatedMethod location: self selector: aSelector)]
I attach a PharoDebug.log with a halt in #collectMethodsFor:into: so that you can see all the stack.
This is the reason why FuelPackageLoader depends on Ring, just for the traits when we do the #addToComposition:.
So...what do we do? we just accept the depedency?
Why not use a CompiledMethod instead? More on, the TraitMethodDescription already knows the selector, so storing only the behaviors containing related methods should be enough...
cheers
-- Mariano http://marianopeck.wordpress.com
participants (2)
-
Guillermo Polito -
Mariano Martinez Peck