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