Traits versus packages

> Hi all,
>
> quick question.
>
> Preamble: If I have a trait TAMStructuralZoom defined in the package AspectMaps (for example), and I want to apply it to the class FAMIXNamespace, defined in the package Famix-Core (for example), this implies that I need to change the class definition of FAMIXNamespace like this:
> FAMIXScopingEntity subclass: #FAMIXNamespace
> uses: TAMStructuralZoom
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Famix-Core'
>
> Question: this change is now part of the Famix-Core package, right? Is it possible for this change to be part of the AspectMaps package? I want this for the obvious modularity & source code management advantages.
> --
> Johan Fabry  
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

> so far (and similarly to instance variable) you cannot with the current definition syntax
> declare a trait (add instance) to a class from a package that does not define the class.
> You can do that in the initialize of a class loaded in a package but there is no think like
>
> MyClass addInstanceVariable: 'x'
> MyOtherClass addTrait:
>
> at the similar syntax level than
>
>> FAMIXScopingEntity subclass: #FAMIXNamespace
>> uses: TAMStructuralZoom
>> instanceVariableNames: ''
>> classVariableNames: ''
>> poolDictionaries: ''
>> category: 'Famix-Core'
>
> this is why one day packages will have to be a bit better supported and more important
> we will have  fix the "semantics" of changeset to be something than a simple side effect of 'oh this is easy' just save the class def and the method definition (because a class is a complex object).

>
> On 28 Apr 2010, at 01:56, Stéphane Ducasse wrote:
>
>> so far (and similarly to instance variable) you cannot with the current definition syntax
>> declare a trait (add instance) to a class from a package that does not define the class.
>> You can do that in the initialize of a class loaded in a package but there is no think like
>>
>> MyClass addInstanceVariable: 'x'
>> MyOtherClass addTrait:
>>
>> at the similar syntax level than
>>
>>> FAMIXScopingEntity subclass: #FAMIXNamespace
>>> uses: TAMStructuralZoom
>>> instanceVariableNames: ''
>>> classVariableNames: ''
>>> poolDictionaries: ''
>>> category: 'Famix-Core'
>>
>> this is why one day packages will have to be a bit better supported and more important
>> we will have  fix the "semantics" of changeset to be something than a simple side effect of 'oh this is easy' just save the class def and the method definition (because a class is a complex object).
>
> --
> Johan Fabry  
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

>
> On 28 Apr 2010, at 01:56, Stéphane Ducasse wrote:
>
>> so far (and similarly to instance variable) you cannot with the  
>> current definition syntax
>> declare a trait (add instance) to a class from a package that does  
>> not define the class.
>> You can do that in the initialize of a class loaded in a package  
>> but there is no think like
>>
>> MyClass addInstanceVariable: 'x'
>> MyOtherClass addTrait:
>>
>> at the similar syntax level than
>>
>>> FAMIXScopingEntity subclass: #FAMIXNamespace
>>> uses: TAMStructuralZoom
>>> instanceVariableNames: ''
>>> classVariableNames: ''
>>> poolDictionaries: ''
>>> category: 'Famix-Core'
>>
>> this is why one day packages will have to be a bit better supported  
>> and more important
>> we will have  fix the "semantics" of changeset to be something than  
>> a simple side effect of 'oh this is easy' just save the class def  
>> and the method definition (because a class is a complex object).
>
> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

>> Or can we make a traits installer, that performs the redefinition  
>> of target classes? First check if the target classes already  
>> declare a uses:, and if not add it. Sounds like simple  
>> metaprogramming ...
>>
>> Any comments on this 'solution'?
>
> Although not perfect, it is easy and efficient.
>
> Alexandre
>
>>
>> On 28 Apr 2010, at 01:56, Stéphane Ducasse wrote:
>>
>>> so far (and similarly to instance variable) you cannot with the  
>>> current definition syntax
>>> declare a trait (add instance) to a class from a package that does  
>>> not define the class.
>>> You can do that in the initialize of a class loaded in a package  
>>> but there is no think like
>>>
>>> MyClass addInstanceVariable: 'x'
>>> MyOtherClass addTrait:
>>>
>>> at the similar syntax level than
>>>
>>>> FAMIXScopingEntity subclass: #FAMIXNamespace
>>>> uses: TAMStructuralZoom
>>>> instanceVariableNames: ''
>>>> classVariableNames: ''
>>>> poolDictionaries: ''
>>>> category: 'Famix-Core'
>>>
>>> this is why one day packages will have to be a bit better  
>>> supported and more important
>>> we will have  fix the "semantics" of changeset to be something  
>>> than a simple side effect of 'oh this is easy' just save the class  
>>> def and the method definition (because a class is a complex object).
>>
>> --
>> Johan Fabry
>> [hidden email] - http://dcc.uchile.cl/~jfabry
>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

> It also should be noted that it is completely obscure when trying to understand a piece of code :)
>
> Cheers,
> Doru
>
>
> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote:
>
>>> Or can we make a traits installer, that performs the redefinition of target classes? First check if the target classes already declare a uses:, and if not add it. Sounds like simple metaprogramming ...
>>>
>>> Any comments on this 'solution'?
>>
>> Although not perfect, it is easy and efficient.
>>
>> Alexandre
>

>
> Not necessarily, the browser should display uses: TraitX, like it  
> does now. So when browsing the code there is no perceived difference.
>
> On 29 Apr 2010, at 03:07, Tudor Girba wrote:
>
>> It also should be noted that it is completely obscure when trying  
>> to understand a piece of code :)
>>
>> Cheers,
>> Doru
>>
>>
>> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote:
>>
>>>> Or can we make a traits installer, that performs the redefinition  
>>>> of target classes? First check if the target classes already  
>>>> declare a uses:, and if not add it. Sounds like simple  
>>>> metaprogramming ...
>>>>
>>>> Any comments on this 'solution'?
>>>
>>> Although not perfect, it is easy and efficient.
>>>
>>> Alexandre
>>
>
> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

> Sure, but if I had the extension loaded and I would want to work on the base class and add an instance variable, I would have a problem, no? :)
>
> Doru
>
>
> On 29 Apr 2010, at 16:10, Johan Fabry wrote:
>
>>
>> Not necessarily, the browser should display uses: TraitX, like it does now. So when browsing the code there is no perceived difference.
>>
>> On 29 Apr 2010, at 03:07, Tudor Girba wrote:
>>
>>> It also should be noted that it is completely obscure when trying to understand a piece of code :)
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote:
>>>
>>>>> Or can we make a traits installer, that performs the redefinition of target classes? First check if the target classes already declare a uses:, and if not add it. Sounds like simple metaprogramming ...
>>>>>
>>>>> Any comments on this 'solution'?
>>>>
>>>> Although not perfect, it is easy and efficient.
>>>>
>>>> Alexandre
>>>
>>
>> --
>> Johan Fabry
>> [hidden email] - http://dcc.uchile.cl/~jfabry
>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
> --
> www.tudorgirba.com
>
> "It's not how it is, it is how we see it."
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

>
> Not necessarily, the browser should display uses: TraitX, like it  
> does now. So when browsing the code there is no perceived difference.
>
> On 29 Apr 2010, at 03:07, Tudor Girba wrote:
>
>> It also should be noted that it is completely obscure when trying  
>> to understand a piece of code :)
>>
>> Cheers,
>> Doru
>>
>>
>> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote:
>>
>>>> Or can we make a traits installer, that performs the redefinition  
>>>> of target classes? First check if the target classes already  
>>>> declare a uses:, and if not add it. Sounds like simple  
>>>> metaprogramming ...
>>>>
>>>> Any comments on this 'solution'?
>>>
>>> Although not perfect, it is easy and efficient.
>>>
>>> Alexandre
>>
>
> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

>
> Not necessarily ;-) if the browser displays the uses: TraitX  
> (because it was added by the extension) and you add an instance var,  
> you are going to do that with the uses: TraitX because that's what's  
> displayed in the pane where you add the instance vars. Unless you  
> manually remove it because you are a nasty person... and then you  
> are just shooting yourself in the foot anyway. :-)
>
> Now on traits unload this has to be done in a clever way, not simply  
> reverting to the state before traits load to avoid losing any other  
> changes made.
>
> On 29 Apr 2010, at 10:15, Tudor Girba wrote:
>
>> Sure, but if I had the extension loaded and I would want to work on  
>> the base class and add an instance variable, I would have a  
>> problem, no? :)
>>
>> Doru
>>
>>
>> On 29 Apr 2010, at 16:10, Johan Fabry wrote:
>>
>>>
>>> Not necessarily, the browser should display uses: TraitX, like it  
>>> does now. So when browsing the code there is no perceived  
>>> difference.
>>>
>>> On 29 Apr 2010, at 03:07, Tudor Girba wrote:
>>>
>>>> It also should be noted that it is completely obscure when trying  
>>>> to understand a piece of code :)
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>> On 28 Apr 2010, at 20:03, Alexandre Bergel wrote:
>>>>
>>>>>> Or can we make a traits installer, that performs the  
>>>>>> redefinition of target classes? First check if the target  
>>>>>> classes already declare a uses:, and if not add it. Sounds like  
>>>>>> simple metaprogramming ...
>>>>>>
>>>>>> Any comments on this 'solution'?
>>>>>
>>>>> Although not perfect, it is easy and efficient.
>>>>>
>>>>> Alexandre
>>>>
>>>
>>> --
>>> Johan Fabry
>>> [hidden email] - http://dcc.uchile.cl/~jfabry
>>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-users mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>>
>> --
>> www.tudorgirba.com
>>
>> "It's not how it is, it is how we see it."
>>
>>
>> _______________________________________________
>> Pharo-users mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
>
> --
> Johan Fabry
> [hidden email] - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

> Hi,
>
> Let me explain: I have ClassX that is extended to use TraitX. Now, I want to add an instance variable to the main class while the extension is loaded.
>
> You would go to ClassX and edit it:
>
> Object subclass: #ClassX
> uses: TraitX
> instanceVariableNames: 'newInstanceVariable'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Base-Category'
>
> Now, if you save, the uses: clause will go in the base class. So, if I publish the package that only contains the base class I will have an unwanted side effect: the base version of ClassX will use TraitX.
>
> Cheers,
> Doru
>
>
> On 29 Apr 2010, at 18:01, Johan Fabry wrote:
>
>>
>> Not necessarily ;-) if the browser displays the uses: TraitX (because it was added by the extension) and you add an instance var, you are going to do that with the uses: TraitX because that's what's displayed in the pane where you add the instance vars. Unless you manually remove it because you are a nasty person... and then you are just shooting yourself in the foot anyway. :-)
>>
>> Now on traits unload this has to be done in a clever way, not simply reverting to the state before traits load to avoid losing any other changes made.