Hi Guys, I looked a bit in more detail at the class extensions problem. Here I bring a bit more to the discussion table. I attach a Snaut screenshot of an analysis session of Hapax + Code Foo. (seems attachment is too big for the mailinglist so here's a link: http://www.inf.unisi.ch/phd/lungu/files/ClassExtensionsInMoose.png) The panel on the right is the detail of the 91 invocations abstracted in the high-level dependency between Hapax Development and Visual Works. To the right of every method which is extended in a different package thabn Base VisualWorks you can see that package. What you will see is that althoug most of those dependencies are defined in othe packages than VisualWorks Base they still are abstracted in the relationship between Hapax and VisualWorks base. You will see that there is a dependency between hapax and Number>>pythag: which methoid is defined in Hapax itself. The reason is the following. A method, even when it is an extension (isExtension is True) belongsTo a class. And the class, logically, belongs to the namespace where it was initially defined and is, logically, packaged in the package it was initially defined in. When I compute the high- level depedencies in softwarenaut i aggregate them from methods to classes and from there up along the namespace of package hierarchy. Since the extended methods are placed in their original classes, I end up with dependencies between the wrong packages. The high-level dependencies in softwarenaut are wrong because the model can not express the existence of class extensions.

I can see two solutions: - we introduce a FAMIXClassExtension as an explicit entity which is a class which has a reference to the extended class. maybe we can even introduce a new relationship which is Class Extension.

- we piggyback the class extensions on top of the classes in a similar way the metaclasses are implemented. In our example, for Collection we would define a Collection class in CodeFoo, SqueakExtensions, EyeSee and ech one of these would only contain the methods that it defines. I am interested if anybody else is interested in this. And I want to hear your opinions.

Cheers, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

We could have something like: FAMIXAssociation subclass: #FAMIXClassExtension instanceVariableNames: 'extendedClass methods belongTo' classVariableNames: '' poolDictionaries: '' category: 'Famix-Core' belongTo will then point to the extending package

poolDictionaries: '' category: 'Famix-Core'

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

> 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

On 27 mai 09, at 15:24, Simon Denier wrote: > > 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) Did that today (not the importer, just the API) and updated the tests in consequence. As ref, here is the API in PhaMoose/Famix3 FAMIXMethod #isExtension "true if the method is a class extension (parentPackage retrieves the package which makes the extension)" FAMIXClass #isExtended true is the class is extended by other packages, i.e. has some class extensions #extendedInPackages returns the packages which extend this class #extendedMethods returns the methods which are extensions of this class #localMethods, #definedMethods (alias, deprecated) returns locally defined methods, i.e. defined in the same package as the class FAMIXClass#methods returns all methods defined in a class, including class extensions. FAMIXPackage #extensionMethods returns the class extensions made by this package #localMethods returns methods locally defined in the package #extensionClasses returns classes extended by THIS package #localClasses, #definedClasses (alias, deprecated) returns classes defined in the package (including extenDED classes) #extendedClasses returns local classes extended by OTHER packages FAMIXPackage#classes returns localClasses FAMIXPackage#methods returns localMethods and extensionMethods I hope it clears a few things. I tried to get a concise yet consistent name format, but you are welcome to comment. In particular, some confusion is possible between #extensionClasses and #extendedClasses > > 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 > > > -- Simon _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 29 mai 09, at 00:54, Alexandre Bergel wrote: > I am glad to see your fixes. > Your tests go green for me. Well, they should not :) Two tests should fail because I didnt patch the importer yet. > > > Cheers, > Alexandre > > > On 28 May 2009, at 11:53, Simon Denier wrote: > >> >> On 27 mai 09, at 15:24, Simon Denier wrote: >> >>> >>> 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) >> >> Did that today (not the importer, just the API) and updated the >> tests in consequence. >> >> As ref, here is the API in PhaMoose/Famix3 >> >> FAMIXMethod >> #isExtension >> "true if the method is a class extension (parentPackage retrieves >> the package which makes the extension)" >> >> FAMIXClass >> #isExtended >> true is the class is extended by other packages, i.e. has some >> class extensions >> #extendedInPackages >> returns the packages which extend this class >> #extendedMethods >> returns the methods which are extensions of this class >> #localMethods, #definedMethods (alias, deprecated) >> returns locally defined methods, i.e. defined in the same package >> as the class >> >> FAMIXClass#methods returns all methods defined in a class, >> including class extensions. >> >> FAMIXPackage >> #extensionMethods >> returns the class extensions made by this package >> #localMethods >> returns methods locally defined in the package >> #extensionClasses >> returns classes extended by THIS package >> #localClasses, #definedClasses (alias, deprecated) >> returns classes defined in the package (including extenDED classes) >> #extendedClasses >> returns local classes extended by OTHER packages >> >> FAMIXPackage#classes returns localClasses >> FAMIXPackage#methods returns localMethods and extensionMethods >> >> >> I hope it clears a few things. I tried to get a concise yet >> consistent name format, but you are welcome to comment. >> In particular, some confusion is possible between >> #extensionClasses and #extendedClasses >> >>> >>> 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 >>> >>> >>> >> >> -- >> Simon >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> 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. Hi Simon, I was meaning to prepare a screencast of Softwarenaut for a long time. I gave a shot at it today. Have a look at: http://vimeo.com/4889339 I hope it answers some of your Softwarenaut questions. Let me know if there is anything else you want to learn about. Cheers, Mircea. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> 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. Hi Simon, I was meaning to prepare a screencast of Softwarenaut for a long time. I gave a shot at it today. Have a look at: http://vimeo.com/4889339 I hope it answers some of your Softwarenaut questions. Let me know if there is anything else you want to learn about.