In the paper it says that

self assert: (C>>#c) origin = C.

when method 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 <stephane.ducasse@inria.fr> 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