Hi Mircea
Do you have some doc on the principles behind Software Naut/way to use it. Because I always found it obscure yet I'm interested. Actually I have been playing with Mondrian in the past few days to get something more or less similar (at least in goal terms) with software naut.
So I stumble upon the same problem as you when dealing with dependencies between packages. Sure the possibility of having ClassExtension and ExtensionRelationship is interesting in the long term. In particular it could simplify some viz as you noticed (Jannik had this problem in DSM, where we want to show class extensions too).
Meanwhile, I will explain the short-term solution in Famix3 with the Pharo importer. FamixMethod has a #parentPackage attribute (should be #packagedIn in Famix2) which points to the most specific package it belongs to. If it's an ordinary method, it points to the same package as its parent class (might be room for space optimization here). If it's a class extension, then it points to the package which makes the extension. This is detected and done by the Smalltalk importer in Pharo. I dont know whether this is the case in VW with Famix2, but it should be possible to do the same (since FAMIX2Method also has a packagedIn attribute)
When looking for dependencies, I start from the packages down to the methods, hence easily check whether a method is part of the package or part of a class extensions. This is enough for the task at hand, but might be cumbersome for other things (where having first-class class extensions would help).
In the near time, two areas which need improvement: - the way the importer currently works, it takes into account class extensions made by other packages to explicitly imported packages, but does not import class extension made by the imported packages to external packages. - refine the Famix-Smalltalk API to easily access class extension from/ to FamixClass and FamixPackage (this is partially done, but only as a bi-relation between packages and extended classes, we dont have the methods)
So if you have time to do a clean improvement of Famix for extensions, do it (there might be some gotcha points as Alex notices). I believe it is possible to find a work around with the current model.
On 27 mai 09, at 13:19, Alexandre Bergel wrote:
I understand your point
FAMIXClass subclass: #FAMIXClassExtension instanceVariableNames: '' classVariableNames: ''
poolDictionaries: '' category: 'Famix-Core'
I fear this may be problematic. In the Pharo version of Moose (I haven't checked for VW), FAMIXClass is referenced in a number of places. For example:
- FAMIXInvocation>>isAPotentialIncomingInvocationFor: contains
'invoRVar class = FAMIXClass'
- FAMIXClass>>isADirectSubclassOf: contains 'aClass class =
FAMIXClass'
This suggest that instances of FAMIXClassExtension will probably not be have the same effect when a FAMIXClass is expected. It does not seem to be a big deal though. But why FAMIXClass>>isExtended is not enough?
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon