Comment #2 on issue 606 by jannik.l...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 extensionMethods is already defined as "self privateState cacheAt: #extensionMethods ifAbsentPut: [ self methods select: [ :m| m isExtension ] ]" What I understand is to have: - extensionMethods without changes of the source code - localMethods that we should modify to have the same as Namespace - methods that is a union of extensionMethods and localMethods Am I right ?

Comment #4 on issue 606 by tudor.gi...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 Pretty much, only that localMethods should be definedMethods (it already exists, only with the wrong implementation).

Comment #6 on issue 606 by tudor.gi...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 Right now, the semantics of methods is to provide the extension methods only. So, currently definedMethods returns only the extension methods which is wrong. Given that the famix-extension API currently depends on this, it will raise erroneous results, so we will have to revisit it anyway. We will probably rewrite it in terms of Chef. In any case, perhaps localMethods is better for the moment. We should not depend on this method too much anyway.

Comment #8 on issue 606 by tudor.gi...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 childNamedEntities contains all the directly packagedIn entities, so it will contain the defined classes and the extension methods. The methods defined in classes will be accessible from the classes objects, but they won't be stored directly in package (just like in namespace).

Comment #10 on issue 606 by tudor.gi...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 Hmm, I got confused by some other bug in the importer. Please try the following: - Import Famix-Core - Browse All Packages - You will find 2 packages: The Famix-Core package only contains the extensions, while the Default one contains all the rest of the classes This is a bug, but I do not know what the source is. Maybe it's RPackage, but I do not have time to investigate. In any case, coming back to the current issue, you are right that currently we specify the package of all methods. I think this is against the original intention. For example, we do not specify the packaging of attributes. So, I think we should only provide the package information when it cannot be deduced from a (belongsTo) container.

Comment #12 on issue 606 by tudor.gi...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 Nice summary :). I do not think anything else needs to be updated. Except for the API, but that needs to be reviewed anyway. Do you give it a try, or should I?

Comment #14 on issue 606 by jannik.l...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 I have to redefine parentPackage in FAMIXMethod like that: === parentPackage ^ parentPackage ifNil:[ self belongsTo parentPackage] === Is it ok ? If yes, the source code is ready to be pushed in repo.

Updates: Status: Started Comment #16 on issue 606 by jannik.l...(a)gmail.com: FAMIXPackage>>methods is wrong http://code.google.com/p/moose-technology/issues/detail?id=606 we should fix parentPackage. move this behavior in packageScope