Issue with traits

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

2009/10/21 Andreas Raab <[hidden email]>:
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

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:


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

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

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

Begin forwarded message:


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

done




--
Cédrick

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

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

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

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 ;-)



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

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

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