Looking at the model can slow down loading models (see moosetechnology/Moose#2152) and it may not be needed ... ?

FAMIXBehaviouralEntity>>#numberOfStatements should be a derived property (because it is computed in Pharo)

Remove OldFamixTXXXTest and add tests that do not correspond to the generated tests associated to the traits

Instead of adding this in a sub generator.

Tests dealing with metrics (afferent, efferent, distance) have been skipped to enable the merge between CleaninFamixTraitsBranch and development.
They need to be corrected but existing values are not explained and may be wrong.

Currently, the method propertyNamed: return nil if it is not set.

IMO this is not clean. It force is to do a lot of nil checks or to produce code such as: ^ (self propertyNamed: #BrainClass) = true since the value can be nil.

I would prefer #propertyNamed: to return a NotFound exception if there is nothing set. If we want to manage the nil case, we have #propertyNamed:ifAbsent:

The problematic part now is to manage the migration if we apply this change.

Maybe we could rename the API to property: instead of propertyNamed: and like this we could use deprecation transformation to rewrite with the right method.

propertyNamed: could be transformed into self property: x ifAbsent: [ nil ].

I would like to have some opinions about this.

FamixJavaNamedEntity has a method #parentPackage declaring that its parent has a package as a container.

This is wrong. A method is a named entity and is contained in a class in Java, not in a package.

Tests have been skipped to merge CleaningFamixTraits and development branches.
These tests deal with metrics.
"Be careful not sure about the values"
"FamixGroups must be adapted to FamixNG before correcting. "
"StType does not support allRecursiveTypes whereas JavaType does"

The method FamixTMultipleFileAnchor>>#allFiles was deprecated in moosetechnology/Moose#2172.

I see multiple problems with this deprecation:

• The users where not updated
• The method is generated from a generator and the property was not removed from the generator.
• The old variable was not removed
• The method was not moved in the deprecated packages

Currently they are stored in the private state of the entities.
Should we continue with private states ?
How can we generate models specifying optional properties ?

e.g. Tags, metrics

By default, it looks like they have only the modifier Protected.

We should check (for example by creating a huge Pharo model and looking for other modifier).

Then, we can take the decision to remove #THasModifier or not for FamixStAttribute

A visibility refers only to public, private, protected and so on.
Since each entity will have only one modifier, and not a collection, the way to access it should be changed (no more modifiers include:#toto).
Obviously, methods using modifier may eventually be modified consequently.

linked with moosetechnology/Moose#2098, moosetechnology/Moose#2121, moosetechnology/Moose#2202 and moosetechnology/Moose#2219.

It seems to me that files and folders are options of metamodels at the same level than tags.

Any file-based MM can use them or not. The file and folder generator is independent on the parsers generation the models.

Thus, I am wondering if they should be created and generated in Famix-Generator.

What I would propose it to create real classes File and Folder by hand, and use the private state to make it an option for any model.

The pros of the approach are:

• Anyone who does not wish to use them will not pollute its generator
• Any MM who does not define files and folder can still use them without the need of regenerating a new MM duplicating the original one

For example, currently, the java generator define files and folders. But we might not care about them? They take more memory while not been used. In the other hand, if we remove them and someone want them in the model, they would need to create a new generator and regenerate a full MM.

What do you think?

Currently, the generator has multiple methods to access traits. But sometimes the names are not really good or it lacks comments.

We discussed with Pavel and we think we should have:

• #localTraits
• #allTraits => Local + transitive one at 1 level
• #allTraitsInHierarchy => Local + hierarchy + transtive ones
• #allLocalTraitsInHierarchy => Local + local in hierarchy

Currently, when we create a MooseGroup from a Trait, the name of the Moose begins with a T.
However, it is a class... so it is disturbing!

We should remove this T.

just like #apply:on:oppositeTraits:on: for "reciprocal traits", there could be a generator method to simplify creating association between two classes

These queries only serve to get entities from queries instead of associations
#opposites can do the same

On the other hand, the new 'dependencySource' mechanism (Moose issue 2092) implies that queries do not always return associations (for now we create fake associations, but it does not need to stay like that)

So we must think about what the queries should be and should return. May be it does not need to be always associations

Commit 2a1481e modified FamixGeneratorMM but the MM has not been regenerated before the commit.
So we think that the test checking modifications on MM failed.

Currently, the methods #from and #to are defined in every association. But we have the information in the metamodel. We could use this to implement a generic #from and #to.

notExistentMetricValue is expected to be defined by users of trait "FamixTWithSourceAnchor".
The only other implementation is MooseEntity, which defines this with -1.

This is kind of weird since is not a nice default value and it seems to not be really used.

FMRelationSlot is updating the opposite slot if it exists. But, to do that, it uses instVarAt:put:.

This is a problem because we might have some behavior in the setter that needs to be done.

Instead, we should use #perform:with:

To reproduce the problem it is simple. Create an entity TWithTypes and an entity TType.

Then you add the second one to the first one using #addType: and ask the mooseName. It is not reset. This should be added as test.

This has impact on VerveineJ so the meta-model should be correct
Currently it is considered a local variable

When we export and import a MSE the order of the arguments of the FAMIXParametriezedType can change and it change its mooseName. I propose to sort the arguments by their mooseName.

So the idea is to stop using precooked traits, precooked traits are highly static, and hard to reuse.
Meanwhile in some languages Classes have inner classes in others don't.
This also leads to problems such as unconsistent traits compositions.
I think it would be interesting to experiment on what if we define this kind of concepts as composition rules (kind of parser productions). Like this, when we talk about TClass, we are going to be talking about a TClass defined by the Generator, or even more interesting, by a delegation to a second object in charge of defining this kind of concepts. Allowing us to compose visitors + concept resolvers. Basically the idea is to say:
In this meta model, this entity is kind of a class, but kind of class such as those defined for this generator / or for this generation puntually.

It could be cool if the generator could export the list of possible parents/children/associations in the class comment of entities.

I did a PR to be able to manage traits conflicts by removing methods.

We should also improve the generator to be sure the trait contains the methods to remove. Else we should warn the user that he can remove the specification in the generator.

(not suited for procedural languages)

There are many test methods in FamixTHasModifiers that are specific to some language (mainly Java).

They should be pushed down in the hierarchy

I found methods that had the same AST than generated methods at the exception that they did not had the "generated" pragma.

I propose to add a test to detect those to be able to remove them.

It creates code deplucation and can create problems if we refactore the traits.

Just a convention to adopt
But would mean changing some defaults generators

computeTemporaryVariableCandidateListFor start by declaring a new temporary and do something if this temporary is not nil. Which means it will never get executed.

I think there is a problem in the logic but I don't know enough this code to fix it.

abstract should be an other property that can be applied on class or method --> it has to be removed from kind and from modifier.

linked with moosetechnology/Moose#2098, moosetechnology/Moose#2121 and moosetechnology/Moose#2202.

FamixJava currently generates Namespaces and Packages. It should only generate one.

I propose to remove the one using TPackage since it was working like this in VerveineJ. But rename FamixJavaNamepaces into FamixJavaPackage since people know it under this name in Java.

We discussed this with Nicolas.

Perhaps, we should create a class FamixInterface and FamixImplementation
And remove isInterface from FamixJavaClass and manage consequently allModelPureClasses.

It would perhaps be necessary to add methods to navigate super classes and implemented interface with the same mechanism.

We should not extend FileBasedMetamodelGenerator and use it as a submetamodel.
At the same time, we can convert all its classes into traits

IMO FamixTrait is too big. There is a lot of concepts.
I understand that all might be used to create a metamodel for programming languages.
But I think you can split a bit this generator

FamixTmodule is defined with a counterpart: FamixTDefinedInModule

But if a module contains GlobalVariables, then:

• Module uses FamixTModule and FamixTGlobalVariableScope.
• GlobalVariable uses FamixTDefinedInModule and FamixTGlobalVariable

which means the belongsTo is implemented twice

Even worth because Module is also a TNamespace and the GlobalVariables should also be TNamespaceEntity

related to moosetechnology/Moose#1484

Currently, ALL TAssociations have a source anchor.
However, it can make no sense for some metamodel.
We should add this information lower in the hierarchy, for example, only for the FamixJava and Smalltalk metamodel
Thus, it will reduce the size of the models

(and add tests :) )

Traits de FamixNG

A partir du moment ou on dit que c’est une relation 0..* ajouter la méthode addX (e.g. addAttribute)

Autour des access 3 traits.
Autour des references 3 traits
Autour de l’heritage 4 traits ????
Autour de l’invocation 4 traits mais besoin de renommer tout ca qui correspond a l’invocation OO et créer une invocation non OO.

Attribute: parentType et parentTypeGroup qui est un group contenant l’unique parentType.
TWithAttributes getter/setter + addAttribute + nbOfAtt, nbOfPrivateAtt, nbOfPublicAtt, nbOfProtectedAtt, nbOfRevealedAtt (nbOfPublic + nbOfAccessorMethods)

Function: functionOwner et functionOwnerGroup
Function devrait utiliser TInvocable et TWithInvocations
TWithFunctions: getter/setter PAS de addFunctions

Method: parentType et parentTypeGroup qui est un group contenant l’unique parentType.
Method devrait utiliser TInvocable et TWithInvocations
pq parentTypeIsStub?
pq category alors que ca n’existe qu’en ST?
pq computeNumberOfLinesOfCode ici et pas dans quelque chose qui a un fileAnchor ?
renommer hasClassScope en isClassSide ?
timeStamp utile ici ?
kind
pq pas isAbstract ?
TWithMethods: getter/setter + addMethod
pq methodsDo?
bp metriques

Package: childEntities getter / setter mais PAS addChildEntity
packageOwner
pq packageScope ?
TPackageable : parentOackage et parentPackageGroup
pq isExtension ici le mettre uniquement dans les méthodes en ST
pq packageScope
TWithPackages seul un package peut contenir un autre package donc est-ce qu’on a besoin de ce trait ?
Utilite de TPackageWithClassesGlue (qui ne contient que weithedMethodCount)?

TNamespace discussion migrated to moosetechnology/Moose#1990

TClass : isInterface, isTestCase weightOfAClass
pq isInterface qui devrait être uniquement dans Java
pq isTestCase
pq n’utilise pas TWithAttributes, TWithMethods, TReferenceable, TInheritance…
pq il n’y a pas isAbstract?
TWithClasses : classes uniquement getter

Type
pq clientTypes qui est calcule ?
pq fanIn ?
pq ces métriques ?
pq realType ?
typeContainer comment on va faire si on dit que Type est un NamespaceEntity du coup on aura parentNamespace et typeContainer ? Une solution avoir le meme nom et lors du merge preciser lequel on garde. Si pas meme nom, possibilité de renommer .
TWithTypes : types getter /setter + addType
code bizarre allRecursiveTypes ? + allRecursiveTypesDo
clientTypes voir si on ne peut pas gérer ca au niveau de MooseQuery.
fanOut

providerTypes cf clientTypes.

Can we add some (presumably simple) proerties to entities in an existing MetaModel.
By example, we have a Java MetaModel already defined but it does not have metrics.
How to change it to add metrics ?

Currently we must redefine a new MetaModel, but can we do something simpler ?

We currently have multiple entities in FamixGenerator that are specific to C/C++.

I think we should move them to a C generator.

• FamixTHeader
• FamixTDereferenceInvocation
• FamixTCompilationUnit
  ...

I think the following should be translated as a relation since FamixTFile is not a "primitive" type

((tFileAnchor property: #correspondingFile type: #FamixTFile) 
	comment: 'File associated to this source anchor').

When we create a model it has its metamodel that are the union of its concepts and the concepts of its submetamodels.

However, some concepts of the submetamodels are not used (it is often the case with the FamixFileBasedGenerator).
We should be able to create a model with a shorter metamodel (that will include only the used concept coming from submetamodels)

Precooked entities are TClass, TMethod, ...

That propose a standard combination of traits for some common entities
The problem is that we use them and often add again traits that they already have.
This causes traits conflicts.

So either we clean them and describe them and make sure everything is corret
Or we simply remove them and recreate everything by hand for all models (which we are already doing actully which causes the traits conflicts)

May be could be set in the FileBasedGenerator

Currently #hasSourceText looks if the completeText of a FileAnchor is not empty.

hasSourceText
	^ self completeText isNotEmpty

But this is super inefficient. It will read the all text before returning true or false.
In such a case, I would except to check if the file has at least one character and I stop my research at this point.

Better, I think we should check if the "sourceText" is not empty instead of the completeText.
(so it can detect some altered file (although it should not happen)).
So, I would prefer to check if there is at least one character from "startPos" of the anchor