5 Dec
2011
5 Dec
'11
12:27 p.m.
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
5 Dec
5 Dec
12:33 p.m.
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
12:44 p.m.
Thanks, Nicolas.
On Mon, Dec 5, 2011 at 12:27 PM, Nicolas Anquetil
<nicolas.anquetil(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
1:19 p.m.
On Dec 5, 2011, at 12:44 PM, Tudor Girba wrote:
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?
- 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
1:48 p.m.
>> - 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
3:06 p.m.
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
4766
days inactive
4766
days old
6 comments
5 participants
participants (5)
-
Alexandre Bergel -
Nicolas Anquetil -
Simon Denier -
Stéphane Ducasse -
Tudor Girba