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