Smalltalk › Pharo › Pharo Smalltalk Developers

CompiledMethod>>origin, traits, and bug in RPackage

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Guillermo Polito

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

Camillo Bruni-3

Re: CompiledMethod>>origin, traits, and bug in RPackage

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

Stéphane Ducasse

Re: CompiledMethod>>origin, traits, and bug in RPackage

In reply to this post by Guillermo Polito

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:

Guillermo Polito

Re: CompiledMethod>>origin, traits, and bug in RPackage

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 <[hidden email]> 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

Guillermo Polito

Re: CompiledMethod>>origin, traits, and bug in RPackage

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 <[hidden email]> wrote:

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 <[hidden email]> 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