Issue with traits

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue with traits

Igor Stasenko
Create a trait:

Trait named: #ABBA
        uses: {}
        category: 'ABBA'.

- add a method #foo to ABBA trait

Then create 2 classes which using it:

Object subclass: #ABBAB
        uses: ABBA
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'ABBA'.

Object subclass: #ABBAC
        uses: ABBA
        instanceVariableNames: ''
        classVariableNames: ''
        poolDictionaries: ''
        category: 'ABBA'.


now what i found interesting:

(ABBAB methodDict at: #foo) == (ABBAC methodDict at: #foo)

but as side effect, we got this one:

(ABBAB methodDict at: #foo) methodClass  ==> ABBAC

which i find a bit disturbing :(

I'm not sure if given issue could have a major impact somewhere...
But i would just #clone the trait method before installing it..
Yes, it takes more space, but it makes each of such methods unrelated.

And i strongly assume that these methods should be unrelated, and
moreover, recompiled for each class separately, because
global var in one class could be a class var in another one, so a
trait method, like:

foo
  ^ Bar

will behave depending on class environment.


--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Issue with traits

Igor Stasenko
2009/10/21 Andreas Raab <[hidden email]>:

> Igor Stasenko wrote:
>>
>> now what i found interesting:
>>
>> (ABBAB methodDict at: #foo) == (ABBAC methodDict at: #foo)
>>
>> but as side effect, we got this one:
>>
>> (ABBAB methodDict at: #foo) methodClass  ==> ABBAC
>>
>> which i find a bit disturbing :(
>
> Yes, seems wrong. VERY wrong. Try this:
>
> Object subclass: #BaseA
>
> BaseA>>foo
>  ^42
>
> Object subclass: #BaseB
>
> BaseB>>foo
>  ^13
>
> And then create subclasses of BaseA and BaseB which use your trait and have
> the trait implementation use "^super foo". One of two things should happen:
>
> a) They both return the same (incorrect) value (which would be expected if
> methodClass is the same). In this case it's just plain broken.
>
> b) They both return different values, in which case there is code that
> handles super sends specifically and the sharing is simply an unnecessary
> optimization.
>
> I hope it's the latter case which would mean you only need to throw out the
> test for super sends and do whatever that code was doing to begin with ;-)
>

Ouch... so VM behavior depends on correct methodClass slot. Thanks for
reminding!
I remember that methodClass plays important role (and its important to
have method and its
methodClass being in sync with class where the method installed), but
forgot the details :)

That could lead to even worse results, if you use super sends, and then
in base class , accessing the instance variables in base method. It
could corrupt the memory & crash the VM.

I hope this is already fixed, because the image where i checked it
is quite old one - 3.10.2

> Cheers,
>  - Andreas


--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Issue with traits

Adrian Lienhard
In reply to this post by Igor Stasenko
I've fixed this issue in Pharo a couple of months ago. CompiledMethods  
are not shared anymore, so methodClass returns the expected class. At  
the time I implemented traits (2004?), there were no method properties  
and hence sharing compiled methods worked -- of course except for  
super sends in which case the method was always recompiled (so the  
answer to Andreas' question below is b)).

Cheers,
Adrian


On Oct 21, 2009, at 08:42 , Andreas Raab wrote:

> Igor Stasenko wrote:
>> now what i found interesting:
>> (ABBAB methodDict at: #foo) == (ABBAC methodDict at: #foo)
>> but as side effect, we got this one:
>> (ABBAB methodDict at: #foo) methodClass  ==> ABBAC
>> which i find a bit disturbing :(
>
> Yes, seems wrong. VERY wrong. Try this:
>
> Object subclass: #BaseA
>
> BaseA>>foo
>  ^42
>
> Object subclass: #BaseB
>
> BaseB>>foo
>  ^13
>
> And then create subclasses of BaseA and BaseB which use your trait  
> and have the trait implementation use "^super foo". One of two  
> things should happen:
>
> a) They both return the same (incorrect) value (which would be  
> expected if methodClass is the same). In this case it's just plain  
> broken.
>
> b) They both return different values, in which case there is code  
> that handles super sends specifically and the sharing is simply an  
> unnecessary optimization.
>
> I hope it's the latter case which would mean you only need to throw  
> out the test for super sends and do whatever that code was doing to  
> begin with ;-)
>
> Cheers,
>  - Andreas
>
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Issue with traits

Marcus Denker-3

On 21.10.2009, at 09:41, Adrian Lienhard wrote:

> I've fixed this issue in Pharo a couple of months ago. CompiledMethods
> are not shared anymore, so methodClass returns the expected class. At
> the time I implemented traits (2004?), there were no method properties
> and hence sharing compiled methods worked -- of course except for
> super sends in which case the method was always recompiled (so the
> answer to Andreas' question below is b)).
>

We did a small paper for this years ESUG that describes the changes.
It will be online at esug.org soon with all the other papers.

If somebody wants a copy, I can send it.

        Marcus

--
Marcus Denker  --  [hidden email]
http://www.2denker.de

2denker UG (haftungsbeschränkt)
Sitz Köln
Amtsgericht - Registergericht - Köln, HRB 65065
Geschäftsführer: Christian Denker und Dr. Marcus Denker





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Fwd: [squeak-dev] Re: Issue with traits

Marcus Denker-3
maybe someone should forward this to squeak-dev, I am not subscribed.

Begin forwarded message:

> From: Marcus Denker <[hidden email]>
> Date: 21. Oktober 2009 11:13:01 GMT+02:00
> To: [hidden email]
> Cc: The general-purpose Squeak developers list <[hidden email]
> >
> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits
>
>
> On 21.10.2009, at 09:41, Adrian Lienhard wrote:
>
>> I've fixed this issue in Pharo a couple of months ago.  
>> CompiledMethods
>> are not shared anymore, so methodClass returns the expected class. At
>> the time I implemented traits (2004?), there were no method  
>> properties
>> and hence sharing compiled methods worked -- of course except for
>> super sends in which case the method was always recompiled (so the
>> answer to Andreas' question below is b)).
>>
>
> We did a small paper for this years ESUG that describes the changes.
> It will be online at esug.org soon with all the other papers.
>
> If somebody wants a copy, I can send it.
>
> Marcus
>
> --
> Marcus Denker  --  [hidden email]
> http://www.2denker.de
>
> 2denker UG (haftungsbeschränkt)
> Sitz Köln
> Amtsgericht - Registergericht - Köln, HRB 65065
> Geschäftsführer: Christian Denker und Dr. Marcus Denker
>
>
>
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [squeak-dev] Re: Issue with traits

cedreek
done

2009/10/21 Marcus Denker <[hidden email]>
maybe someone should forward this to squeak-dev, I am not subscribed.

Begin forwarded message:

> From: Marcus Denker <[hidden email]>
> Date: 21. Oktober 2009 11:13:01 GMT+02:00
> To: [hidden email]
> Cc: The general-purpose Squeak developers list <[hidden email]
> >
> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits
>
>
> On 21.10.2009, at 09:41, Adrian Lienhard wrote:
>
>> I've fixed this issue in Pharo a couple of months ago.
>> CompiledMethods
>> are not shared anymore, so methodClass returns the expected class. At
>> the time I implemented traits (2004?), there were no method
>> properties
>> and hence sharing compiled methods worked -- of course except for
>> super sends in which case the method was always recompiled (so the
>> answer to Andreas' question below is b)).
>>
>
> We did a small paper for this years ESUG that describes the changes.
> It will be online at esug.org soon with all the other papers.
>
> If somebody wants a copy, I can send it.
>
>       Marcus
>
> --
> Marcus Denker  --  [hidden email]
> http://www.2denker.de
>
> 2denker UG (haftungsbeschränkt)
> Sitz Köln
> Amtsgericht - Registergericht - Köln, HRB 65065
> Geschäftsführer: Christian Denker und Dr. Marcus Denker
>
>
>
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Cédrick

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Issue with traits

KenDickey
In reply to this post by Igor Stasenko
Why not share the code?  Just use a "cell" to hold the class and have
methodClass accessor do the indirection.

If you have a bit in the method header, the VM could use it as a 0/1 index
into the code to call to do (or not do) the extra indirection.  Just think of
the a trait method as a closure which is parameterized on the class.

Am I missing something deep here?

-KenD

> Message: 7
> Date: Wed, 21 Oct 2009 09:41:08 +0200
> From: Adrian Lienhard <[hidden email]>
> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits
> To: The general-purpose Squeak developers list
>         <[hidden email]>,        Pharo Development
>         <[hidden email]>
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> I've fixed this issue in Pharo a couple of months ago. CompiledMethods  
> are not shared anymore, so methodClass returns the expected class. At  
> the time I implemented traits (2004?), there were no method properties  
> and hence sharing compiled methods worked -- of course except for  
> super sends in which case the method was always recompiled (so the  
> answer to Andreas' question below is b)).
>
> Cheers,
> Adrian

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-KenD
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Issue with traits

Marcus Denker-3

On 21.10.2009, at 22:28, Ken.Dickey wrote:

> Why not share the code?  Just use a "cell" to hold the class and have
> methodClass accessor do the indirection.
>
But based on which info should this indirection be made?

The idea with a simple backpointer was done because it's already there  
in case of super-sends.
So you would need to do something special there again (the last  
literal *has to be* a class
for those methds).

> If you have a bit in the method header, the VM could use it as a 0/1  
> index
> into the code to call to do (or not do) the extra indirection.

If there is something that is a scarce resource, than it's bits in the  
method header. And
I don't get it: there is one header per object, not one per reference.  
Thus
the bit could not be diffrerent per *use* of the compiledMethod.

>  Just think of
> the a trait method as a closure which is parameterized on the class.
>
> Am I missing something deep here?
>

You overlook complexity ;-)


> -KenD
>
>> Message: 7
>> Date: Wed, 21 Oct 2009 09:41:08 +0200
>> From: Adrian Lienhard <[hidden email]>
>> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits
>> To: The general-purpose Squeak developers list
>>         <[hidden email]>,        Pharo  
>> Development
>>         <[hidden email]>
>> Message-ID: <[hidden email]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> I've fixed this issue in Pharo a couple of months ago.  
>> CompiledMethods
>> are not shared anymore, so methodClass returns the expected class. At
>> the time I implemented traits (2004?), there were no method  
>> properties
>> and hence sharing compiled methods worked -- of course except for
>> super sends in which case the method was always recompiled (so the
>> answer to Andreas' question below is b)).
>>
>> Cheers,
>> Adrian
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Issue with traits

Marcus Denker-3
In reply to this post by Marcus Denker-3

On 21.10.2009, at 11:13, Marcus Denker wrote:

>
> On 21.10.2009, at 09:41, Adrian Lienhard wrote:
>
>> I've fixed this issue in Pharo a couple of months ago.  
>> CompiledMethods
>> are not shared anymore, so methodClass returns the expected class. At
>> the time I implemented traits (2004?), there were no method  
>> properties
>> and hence sharing compiled methods worked -- of course except for
>> super sends in which case the method was always recompiled (so the
>> answer to Andreas' question below is b)).
>>
>
> We did a small paper for this years ESUG that describes the changes.
> It will be online at esug.org soon with all the other papers.
>

Here is the pdf:

http://marcusdenker.de/publications/Duca09bTraitsAPI.pdf

        Marcus



--
Marcus Denker  --  [hidden email]
http://www.2denker.de

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project