[ANN] Traits installer/uninstaller utility

> Hi all,
>
> this is a small package that I wrote after doing a traits-based  
> refactoring of AspectMaps (Plug: Check out AspectMaps for a cool  
> visualization of Aspects. http://pleiad.cl/aspectmaps. It has nice  
> screencasts. All comments welcome!)
>
> AspectMaps extends a number of classes of FAMIX to do its thing,  
> using standard class extensions. This works OK when you are not  
> using traits. But when using a trait, you need to redef the class,  
> i.e. change the original package (in this case one of the moose  
> packages). A big no-no. This kind of change should also be  
> encapusulated in the AspectMaps package, but currently this is not  
> possible. So, as long as traits and packages dont play well  
> together, these kinds of refactorings are out.
>
> However not so when you are using the TraitsApplication package.  
> This package provides a means to programmatically install/uninstall  
> traits. Call it in a post-load action on a package (if such a thing  
> exists), in a class initialize method, et cetera (for AspectMaps I  
> do it in the AspectMaps>>open method). I thought this could be  
> useful to some members of the community so I am releasing it  
> publicly. You can find it at http://www.squeaksource.com/TraitsApplication
>
> CAVEAT: This is a quick implementation, it is non-optimal. It can be  
> made much more elegant, but that requires time that I dont have  
> right now :-(. I does not handle fancy trait compositions (yet). I  
> give no guarantees other than that
> 1) it passes all of its tests
> 2) it works for me :-)
>
> So check it out. Comments are welcome!
> --
> 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 Johan,
>
> I took a quick look and it looks interesting.
>
> Just a note for discussion. Executing "AspectMapsUI open" installs the traits. One of your trait extension is adding TAMStructuralZoom to FAMIXClass.
>
> Now, when I browse the FAMIXClass, I get this in the browser:
>
> -----
> FAMIXType subclass: #FAMIXClass
> uses: TAMStructuralZoom
> instanceVariableNames: 'isInterface'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Famix-Core'
> -----
>
> There are two problems with this:
>
> 1. So, now if I just want to edit the base class, I have to take care and delete the Trait before, because the Trait is part of the definition.
>
> This is a limitation of the browser, but we have to pay attention to it.
>
> 2. If you look in Monticello, the base package (FAMIX-Core in this case) is not dirty, but if you explicitly look for Changes, it gets dirty. I do not know how this could be solved. Perhaps we need extension as first class?

>
> Cheers,
> Doru
>
>
> On 16 May 2010, at 02:36, Johan Fabry wrote:
>
>> Hi all,
>>
>> this is a small package that I wrote after doing a traits-based refactoring of AspectMaps (Plug: Check out AspectMaps for a cool visualization of Aspects. http://pleiad.cl/aspectmaps. It has nice screencasts. All comments welcome!)
>>
>> AspectMaps extends a number of classes of FAMIX to do its thing, using standard class extensions. This works OK when you are not using traits. But when using a trait, you need to redef the class, i.e. change the original package (in this case one of the moose packages). A big no-no. This kind of change should also be encapusulated in the AspectMaps package, but currently this is not possible. So, as long as traits and packages dont play well together, these kinds of refactorings are out.
>>
>> However not so when you are using the TraitsApplication package. This package provides a means to programmatically install/uninstall traits. Call it in a post-load action on a package (if such a thing exists), in a class initialize method, et cetera (for AspectMaps I do it in the AspectMaps>>open method). I thought this could be useful to some members of the community so I am releasing it publicly. You can find it at http://www.squeaksource.com/TraitsApplication
>>
>> CAVEAT: This is a quick implementation, it is non-optimal. It can be made much more elegant, but that requires time that I dont have right now :-(. I does not handle fancy trait compositions (yet). I give no guarantees other than that
>> 1) it passes all of its tests
>> 2) it works for me :-)
>>
>> So check it out. Comments are welcome!
>> --
>> 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
>
> "Speaking louder won't make the point worthier."
>
>
> _______________________________________________
> Pharo-users mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users

> Just a note for discussion. Executing "AspectMapsUI open" installs the traits. One of your trait extension is adding TAMStructuralZoom to FAMIXClass.
>
> Now, when I browse the FAMIXClass, I get this in the browser:
>
> -----
> FAMIXType subclass: #FAMIXClass
> uses: TAMStructuralZoom
> instanceVariableNames: 'isInterface'
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Famix-Core'
> -----
>
> There are two problems with this:
>
> 1. So, now if I just want to edit the base class, I have to take care and delete the Trait before, because the Trait is part of the definition.
>
> This is a limitation of the browser, but we have to pay attention to it.

>
> On 16 May 2010, at 03:48, Tudor Girba wrote:
>
>> I took a quick look and it looks interesting.
>
> Thanks :-)
>
>> Just a note for discussion. Executing "AspectMapsUI open" installs  
>> the traits. One of your trait extension is adding TAMStructuralZoom  
>> to FAMIXClass.
>>
>> Now, when I browse the FAMIXClass, I get this in the browser:
>>
>> -----
>> FAMIXType subclass: #FAMIXClass
>> uses: TAMStructuralZoom
>> instanceVariableNames: 'isInterface'
>> classVariableNames: ''
>> poolDictionaries: ''
>> category: 'Famix-Core'
>> -----
>>
>> There are two problems with this:
>>
>> 1. So, now if I just want to edit the base class, I have to take  
>> care and delete the Trait before, because the Trait is part of the  
>> definition.
>>
>> This is a limitation of the browser, but we have to pay attention  
>> to it.
>
> My philosophy here is to not hide anything from the developer, which  
> is why the Trait is part of the definition. What you see is what you  
> get. Delete the Trait when editing the base class and it goes away.  
> What you see is what you get.
>
> So just edit the class as you want to, you can even add new Traits  
> manually. You can always remove the TAMStructuralZoom trait (or any  
> other trait actually) using the traits uninstaller.

>> 2. If you look in Monticello, the base package (FAMIX-Core in this  
>> case) is not dirty, but if you explicitly look for Changes, it gets  
>> dirty. I do not know how this could be solved. Perhaps we need  
>> extension as first class?
>
> OK this should not happen. I tried to be as close to how the browser  
> works when redefining a class (the redefinition even gets recorded  
> in changes) because I want to avoid breaking any magic that is going  
> on. But apparently I did not succeed completely. If any Monticello  
> magicians can tell me what incantation to add I would be most happy  
> to oblige!
>
> --
> 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