[Pharo-project] question on traits
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
Copying methods is probably the right way to do regarding literals and properties. A comparison of the bytecodes may solve this issue although. I added an issue, #725. I will fix it soon. 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Great. I think the simplest thing to do is to check whether the two methods have the same origin (CompiledMethod>>#origin). If they have, they must be the same. So you don't need to compare their bytecode. Adrian On Apr 10, 2009, at 14:48 , Alexandre Bergel wrote:
Copying methods is probably the right way to do regarding literals and properties. A comparison of the bytecodes may solve this issue although. I added an issue, #725. I will fix it soon.
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
2009/4/10 Adrian Lienhard <adi@netstyle.ch>:
Great. I think the simplest thing to do is to check whether the two methods have the same origin (CompiledMethod>>#origin). If they have, they must be the same. So you don't need to compare their bytecode.
yeah, comparing bytecode is not solution, because ^ 'foo' and ^ 'bar' having same bytecode, but different literals.
Adrian
On Apr 10, 2009, at 14:48 , Alexandre Bergel wrote:
Copying methods is probably the right way to do regarding literals and properties. A comparison of the bytecodes may solve this issue although. I added an issue, #725. I will fix it soon.
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
-- Best regards, Igor Stasenko AKA sig.
Although this would be such a big problem, thanks for pointing this out. Cheers, Alexandre On 10 Apr 2009, at 17:35, Igor Stasenko wrote:
2009/4/10 Adrian Lienhard <adi@netstyle.ch>:
Great. I think the simplest thing to do is to check whether the two methods have the same origin (CompiledMethod>>#origin). If they have, they must be the same. So you don't need to compare their bytecode.
yeah, comparing bytecode is not solution, because ^ 'foo' and ^ 'bar'
having same bytecode, but different literals.
Adrian
On Apr 10, 2009, at 14:48 , Alexandre Bergel wrote:
Copying methods is probably the right way to do regarding literals and properties. A comparison of the bytecodes may solve this issue although. I added an issue, #725. I will fix it soon.
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
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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? 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? 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. locatedMethods is tested nowhere and there is no documentation. 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I saved this code in www.squeakSource.com/Traits Cheers, Alexandre On 14 Apr 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?
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? 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. locatedMethods is tested nowhere and there is no documentation.
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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (4)
-
Adrian Lienhard -
Alexandre Bergel -
Alexandre Bergel -
Igor Stasenko