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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr 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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr 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
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr 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."
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr 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."
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr 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 Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr 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 Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-- Johan Fabry jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
-- www.tudorgirba.com "One cannot do more than one can do."
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
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 jfabry@dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-users mailing list Pharo-users@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users
participants (4)
-
Alexandre Bergel -
Johan Fabry -
Stéphane Ducasse -
Tudor Girba