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