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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon