In 102077, btw, this test seems green. (But strangely, #testFileOutCategory fails now.)
Exact, but it failed in a 10259.
The former. LocatedMethod a simple (internal) class that encapsulates a method and the behavior in which the method is implemented. Nowadays, we could probably even avoid this since methods know the behavior they are implemented in (this was not the case before).
Ok. It is clearer now.
Looks good. Both traits tr2 and tr3 provide a method #foo. At the time when LocatedMethod instances are created, no conflicts are resolved (or methods merged) yet. The interesting logic is in TraitMethodDescription (see class comment). If you are at fixing the conflict of methods from the same origin, I think the right place is TraitMethodDescription>>providedLocatedMethod. This method fails (returns nil) if it finds more than one provided method. It should not fail, though, if those methods have the same #origin.
I extended few methods: TraitMethodDescription>>providedLocatedMethod | locatedMethod aLocatedMethod refOrigin | locatedMethod := nil. self locatedMethods ifEmpty: [ ^ nil]. self locatedMethods size > 1 ifTrue: [ aLocatedMethod := self locatedMethods anyOne. refOrigin := (aLocatedMethod location >> aLocatedMethod selector) origin. (self locatedMethods allSatisfy: [:each | each method origin == refOrigin]) ifTrue: [ ^ aLocatedMethod ]]. self locatedMethods do: [:each | each method isProvided ifTrue: [ locatedMethod isNil ifFalse: [^nil]. locatedMethod := each]]. ^locatedMethod TraitMethodDescription>>isConflict | count originMethodReferenciel | count := 0. self locatedMethods size > 1 ifTrue: ["If they are more than 1 located method, then check whether these methods have the same origin" originMethodReferenciel := self locatedMethods anyOne method origin. ((self locatedMethods collect: [:lm | lm method]) allSatisfy: [:each | each method origin == originMethodReferenciel]) ifTrue: [ ^ false ]]. self methodsDo: [:each | each isProvided ifTrue: [ count := count + 1. count > 1 ifTrue: [^true]]]. ^false In providedLocatedMethod, I am not sure about the "^ aLocatedMethod". This does not seem to be a big deal, since the result is checked for nullity only. These two enhanced methods makes testOrigin green. testOrigin is a new test that create a diamond made of 4 traits. The code is available in Traits@SqueakSource. Does this code looks okay? If yes, then I will put it in PharoInbox. Sorry for the long code excerpts. Cheers, Alexandre
Cheers, Alexandre
On 10 Apr 2009, at 14:32, Adrian Lienhard wrote:
Yes, this should not be a conflict. I think I had implemented it that way. Probably it was broken in the recent refactoring that I did for method sharing...
Adrian
On Apr 10, 2009, at 13:47 , Alexandre Bergel wrote:
Hi All,
Apparently, the way a conflict may be triggered is slightly different from what is described in the toplas paper. in the paper, it is said that a compiled method that is inherited from more than one path does not trigger a conflict. With the current implementation this trigger a conflict.
For example: T1 defines foo T2 uses T1 T3 uses T1 T23 uses T2 + T3 C uses T23
C new foo => conflict error.
One would expect no conflict since there is only one definition of foo Just wondering...
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.