I did several "improvements" to MooseChef. Reviews are welcome (Simon if you are around, please read this, specifically, at the end) .
- Created withoutSelfLoops in MooseQueryObjectResult as discussed before (see discussion on MooseChef end of november)
- Renamed all queryXxxIncoming/OutgoingDependencies to queryXxxIncoming/OutgoingAssociations (see discussion on MooseChef & hidden dependencies last week)
- Introduced a virtual association : Instanciation that relates a variable (structuredEntity to its type and a method (behaviouralEntity) to its returnType. I created MooseChefInstanciationAssociation for this. It is not in Famix as it is only intended to do queries.
- Followed up with creating appropriate queryIncoming/OutgoingInstanciations in FamixPackage , FamixClass, FamixMethod
All this has been tested and commited (this morning). Documentation on the web site was not updated
Meanwhile, I performed other modifications/corrections:
- Better comment initiative: commented some MooseQueryResult classes
- FamixPackage and FamixNamespace had the same classScope method that [only makes sense to reject self loops in #collectAtScope:], I moved it to FAMIXScopingEntity.
- I found strange that there was no methodScope method, for consistency, I added it, again in FAMIXScopingEntity.
- Still for consistency, I added a methodScope method to FamixType
Finally, I still have some questions (Simon?)
- the trait TScopingEntityQuery seems to exist only to be added to FamixScopingEntity. Is that so?
Why having a trait in this case? Consistency? If so, may be it should be documented (comment).
- MooseOutgoingCompositionQueryResult does not use TDependencyQueryResult whereas its sisters (MooseOutgoing/IncommingQueryResult) do. This means MooseOutgoingCompositionQueryResult is lacking many selectors that its sisters have (opposites, ...)
Error or feature?
nicolas
All this has been tested and commited (this morning). Documentation on the web site was not updated
Would be cool to update the web doc.
Alexandre
Thanks, Nicolas.
On Mon, Dec 5, 2011 at 12:27 PM, Nicolas Anquetil nicolas.anquetil@inria.fr wrote:
I did several "improvements" to MooseChef. Reviews are welcome (Simon if you are around, please read this, specifically, at the end).
- Created withoutSelfLoops in MooseQueryObjectResult as discussed before
(see discussion on MooseChef end of november)
I will review that.
- Renamed all queryXxxIncoming/OutgoingDependencies to
queryXxxIncoming/OutgoingAssociations (see discussion on MooseChef & hidden dependencies last week)
I saw this one. Great.
- Introduced a virtual association : Instanciation that relates a variable
(structuredEntity to its type and a method (behaviouralEntity) to its returnType. I created MooseChefInstanciationAssociation for this. It is not in Famix as it is only intended to do queries.
I am not sure about introducing this entity.
In any case, the name is not good because: - Instanciation is not a word (Instantiation is) :) - instantiation conflicts with the dynamic meaning used in Dynamix
I would suggest MooseChefTypeDeclaration.
- Followed up with creating appropriate queryIncoming/OutgoingInstanciations
in FamixPackage, FamixClass, FamixMethod
All this has been tested and commited (this morning). Documentation on the web site was not updated
Meanwhile, I performed other modifications/corrections:
Better comment initiative: commented some MooseQueryResult classes
FamixPackage and FamixNamespace had the same classScope method that [only
makes sense to reject self loops in #collectAtScope:], I moved it to FAMIXScopingEntity.
- I found strange that there was no methodScope method, for consistency, I
added it, again in FAMIXScopingEntity.
- Still for consistency, I added a methodScope method to FamixType
Finally, I still have some questions (Simon?)
- the trait TScopingEntityQuery seems to exist only to be added to
FamixScopingEntity. Is that so?
Why having a trait in this case? Consistency? If so, may be it should be documented (comment).
- MooseOutgoingCompositionQueryResult does not use TDependencyQueryResult
whereas its sisters (MooseOutgoing/IncommingQueryResult) do. This means MooseOutgoingCompositionQueryResult is lacking many selectors that its sisters have (opposites, ...)
Error or feature?
nicolas
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Dec 5, 2011, at 12:44 PM, Tudor Girba wrote:
- Introduced a virtual association : Instanciation that relates a variable
(structuredEntity to its type and a method (behaviouralEntity) to its returnType. I created MooseChefInstanciationAssociation for this. It is not in Famix as it is only intended to do queries.
I am not sure about introducing this entity.
why do we need an association for the type of a variable and the returned type of a method? we can explode memory with that?
In any case, the name is not good because:
- Instanciation is not a word (Instantiation is) :)
- instantiation conflicts with the dynamic meaning used in Dynamix
- Introduced a virtual association : Instanciation that relates a
variable (structuredEntity to its type and a method (behaviouralEntity) to its returnType. I created MooseChefInstanciationAssociation for this. It is not in Famix as it is only intended to do queries.
I am not sure about introducing this entity.
I first tries to do a purely virtual association (i.e. having queryIncomingInstantiation working directly with class>>structuresWithDeclaredType), but I couldn't find a nice way to do it. With a new class (it is not in Famix, so it is not an entity) it fits easily in the existing MooseChef framework.
why do we need an association for the type of a variable and the returned type of a method? we can explode memory with that?
It is not in Famix, it is used only for MooseChef queries. These virtual associations are created temporarily for the life time of the query. It allows MooseChef to access in a uniform way the dependency between a variable and its type or a method and its returnType. For Smalltalk it does not change much, but for Java, many dependencies between classes remain hidden to MooseChef without something like this.
nicolas
On 5 déc. 2011, at 12:27, Nicolas Anquetil wrote:
Finally, I still have some questions (Simon?)
- the trait TScopingEntityQuery seems to exist only to be added to FamixScopingEntity. Is that so?
Why having a trait in this case? Consistency? If so, may be it should be documented (comment).
Yes. It seemed more appropriate to create a generic container specializing TDependencyQueries for "scopes". At least it keeps most generic things related to MooseChef close together (in dedicated classes/traits): only the most specific stuff goes into Famix classes.
Also, it's kind of a by-product of MooseChef evolution (at first I wasn't sure how much could be generalized from Package and Namespace - it just gradually evolved into this thing).
- MooseOutgoingCompositionQueryResult does not use TDependencyQueryResult whereas its sisters (MooseOutgoing/IncommingQueryResult) do. This means MooseOutgoingCompositionQueryResult is lacking many selectors that its sisters have (opposites, ...)
Error or feature?
Feature at the time, error if you want. It's just not always possible to tell what's the right semantics for every possible combination of queries + selectors.
In that case, since MooseOutgoingCompositionQueryResult groups different kinds of associations, I didn't have a use case where I would request 'opposites' of a composite result which includes invocations as well as references, etc : it would return a bunch of classes and methods. Now it could be useful for a consistent API, but I don't see a use case.
-- Simon Denier
-
Alexandre Bergel -
Nicolas Anquetil -
Simon Denier -
Stéphane Ducasse -
Tudor Girba