Traits versus packages

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

Traits versus packages

jfabry
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
Reply | Threaded
Open this post in threaded view
|

Re: Traits versus packages

Stéphane Ducasse
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).


> 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


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

Re: Traits versus packages

jfabry

Booh. So far for the traits implementation of AspectMaps then :-( I dont want to break the modularity of the AspectMaps package by requireing a special version of other packages for the traits to work.

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'?

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
Reply | Threaded
Open this post in threaded view
|

Re: Traits versus packages

Stéphane Ducasse

On Apr 28, 2010, at 7:03 PM, Johan Fabry wrote:

>
> Booh. So far for the traits implementation of AspectMaps then :-( I dont want to break the modularity of the AspectMaps package by requireing a special version of other packages for the traits to work.
>
> 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'?

should work.
sometimes we did that for adding a new instance variable to a class when loading a package

>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Traits versus packages

Alexandre Bergel-4
In reply to this post by jfabry
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Traits versus packages

Tudor Girba
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
>
>>
>> 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

--
www.tudorgirba.com

"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."


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

Re: Traits versus packages

jfabry

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
Reply | Threaded
Open this post in threaded view
|

Re: Traits versus packages

Tudor Girba
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
Reply | Threaded
Open this post in threaded view
|

Re: Traits versus packages

jfabry

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
Reply | Threaded
Open this post in threaded view
|

Re: Traits versus packages

Alexandre Bergel-4
In reply to this post by jfabry
One of the thing that it may hamper readibility, is when browsing the  
code through a Monticello Browser or a webbrowser.

Alexandre


On 29 Apr 2010, at 10: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


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

Re: Traits versus packages

Tudor Girba
In reply to this post by jfabry
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.
>
> 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

--
www.tudorgirba.com

"One cannot do more than one can do."




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

Re: Traits versus packages

jfabry

Indeed.  Maybe hook into Monticello to detect that a publish will be done and then do an unload, and after the publish a load. This system is getting to be a bit fiddly, but I see no fundamental solution. That is until the entire package mechanism becomes more powerful in this regard.

On 30 Apr 2010, at 09:06, Tudor Girba wrote:

> 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.

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