moosetechnology / famix Goto Github PK
View Code? Open in Web Editor NEWAn abstract representation of source code. Famix is generic and can describe applications in multiple programming languages.
License: MIT License
An abstract representation of source code. Famix is generic and can describe applications in multiple programming languages.
License: MIT License
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"
Remove OldFamixTXXXTest and add tests that do not correspond to the generated tests associated to the traits
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.
(not suited for procedural languages)
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 :) )
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
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 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:
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 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.
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:
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.
group := MooseGroup withAll: { MooseEntity new. MooseEntity new }.
group ifEmpty: [ 'Nothing' ].
"an OrderedCollection(a MooseEntity #noname a MooseEntity #noname)" ```
The method FamixTMultipleFileAnchor>>#allFiles was deprecated in moosetechnology/Moose#2172.
I see multiple problems with this deprecation:
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
This has impact on VerveineJ so the meta-model should be correct
Currently it is considered a local variable
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.
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.
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.
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.
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.
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
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
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.
There are many test methods in FamixTHasModifiers
that are specific to some language (mainly Java).
They should be pushed down in the hierarchy
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)
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.
Just a convention to adopt
But would mean changing some defaults generators
FAMIXBehaviouralEntity>>#numberOfStatements should be a derived property (because it is computed in Pharo)
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.
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
May be could be set in the FileBasedGenerator
We currently have multiple entities in FamixGenerator that are specific to C/C++.
I think we should move them to a C generator.
We should not extend FileBasedMetamodelGenerator and use it as a submetamodel.
At the same time, we can convert all its classes into traits
just like #apply:on:oppositeTraits:on:
for "reciprocal traits", there could be a generator method to simplify creating association between two classes
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.
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)
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 ?
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.
It could be cool if the generator could export the list of possible parents/children/associations in the class comment of entities.
Instead of adding this in a sub generator.
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.
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').
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.
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.
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.
FamixTmodule is defined with a counterpart: FamixTDefinedInModule
But if a module contains GlobalVariables, then:
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
Looking at the model can slow down loading models (see moosetechnology/Moose#2152) and it may not be needed ... ?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.