Hi Alex, On Apr 14, 2009, at 15:14 , Alexandre Bergel wrote:
Hi Adrian and all traits friends,
The test TraitTest>>testLocalMethodWithSameCodeInTrait is yellow. I guess this is because there is no sharing of compiled methods. This test is therefore not irrelevant right? Can be safely removed?
No. This test finds methods that are implemented in a class (or trait) that are equal to a method that could be obtained from a trait. This can happen if you accidentally recompile a method in a class instead of in the trait. In 102077, btw, this test seems green. (But strangely, #testFileOutCategory fails now.)
Something slightly more technical. What providedLocatedMethod should return? What a LocatedMethod should refer to? A location of a method in a trait, or where the method is defined for the first time?
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).
An example. Let's assume I have:
tr1 := self createTraitNamed: #T1 uses: {}. tr2 := self createTraitNamed: #T2 uses: {tr1}. tr3 := self createTraitNamed: #T3 uses: {tr1}. tr23 := self createTraitNamed: #T23 uses: {tr3 + tr2}. tr1 compile: 'foo ^ 4'.
aMethodDescription := tr23 traitComposition methodDescriptionForSelector: #foo. self assert: (aMethodDescription locatedMethods size = 2). self assert: (aMethodDescription locatedMethods includes: (LocatedMethod location: tr2 selector: #foo)). self assert: (aMethodDescription locatedMethods includes: (LocatedMethod location: tr3 selector: #foo)).
The last two assertion pass. However, is it that intended? I would have expected only one locatedMethod, which is (LocatedMethod location: tr1 selector: #foo), however I am not sure.
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.
locatedMethods is tested nowhere and there is no documentation.
Well, it has a class comment and there are unit tests in the class LocatedMethodTest. (According to the test runner's "Run Coverage", the class even is completely covered.) HTH, Adrian
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