[Pharo-project] CompiledMethod>>origin, traits, and bug in RPackage
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
Hi guillermo.... I somehow fixed that by putting the origin in the method properties themselves. this seems to be rather simple and so far worked :D => check slice http://code.google.com/p/pharo/issues/detail?id=5696 which solves quite some issue on that front => maybe you can address the two left issue with this slice? On 2012-04-28, at 01:02, 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
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
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 <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
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 <guillermopolito@gmail.com
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 < 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
participants (3)
-
Camillo Bruni -
Guillermo Polito -
Stéphane Ducasse