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
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
