This test reproduces the problem :)
testOriginWithRequiredMethod
| tr1 c1 |
tr1 := self createTraitNamed: #TTT1 uses: {}.
tr1 compile: 'foo ^ self explicitRequirement'.
self assert: (tr1 >> #foo) origin == tr1.
c1 := self createClassNamed: #CTT1 superclass: Object uses: tr1.
self assert: (c1 >> #foo) origin == tr1.
I'll submit an issue to integrate it.
On Sat, Apr 28, 2012 at 4:41 PM, Guillermo Polito <[email protected]
> wrote:
> In the paper it says that
>
> self assert: (C>>#c) origin = C.
>
> when m*ethod c is defined locally in class C*, which overrides its defi-
> nition from Trait2. Its origin is then such a class C.
>
> And the definition does not stand any limitations on requirements... :/
>
> I'll write some tests.
>
>
>
> On Sat, Apr 28, 2012 at 9:21 AM, Stéphane Ducasse <
> [email protected]> wrote:
>
>> We should check that what we described in
>> http://marcusdenker.de/publications/Duca09bTraitsAPI.pdf
>>
>> Stef
>>
>>
>> On Apr 28, 2012, at 1:02 AM, Guillermo Polito wrote:
>>
>> > For example, the trait TPureBehavior has the method #traitComposition,
>> which is an explicit requirement, and I can do
>> > I have that:
>> >
>> > (TPureBehavior>>#traitComposition) origin. --> TPureBehavior
>> >
>> > which is nice.
>> > Now lets suppose I create:
>> >
>> > Object subclass: #AAA
>> > uses: TPureBehavior
>> > instanceVariableNames: ''
>> > classVariableNames: ''
>> > poolDictionaries: ''
>> > category: 'Guille'
>> >
>> > without creating the required traitComposition method
>> >
>> > (AAA>>#traitComposition) origin. --> AAA ?????????? shouldn't the
>> origin be TPureBehavior?
>> >
>> >
>> > The question is: Which is the intended behavior for the #origin of a
>> method? Because that's causing an issue in RPackage :).
>> >
>> >
>> > I've traced this, and it comes that if I have a trait method marked as
>> explicitRequiriment, the following method answers just false
>> >
>> > CompiledMethod>>isProvided: marker
>> > marker ifNil: [^ true].
>> > ^ (self isRequired: marker) not and: [(self isDisabled: marker) not]
>> >
>> > and then a magic ifNone: [ self ] return the receiver on the behavior,
>> and that's why in both examples the method's behavior is returned instead
>> of the origin.
>> > Then we probably should have two methods
>> > - #isProvided to see if an implementation is provided
>> > - #isDefined if a definition for the method exists
>> > but those names do not make me happy.
>> >
>> > Guille
>>
>>
>>
>
