Smalltalk › Frameworks & Tools › Moose

Several modifications to MooseChef

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Nicolas Anquetil

Several modifications to MooseChef

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: Several modifications to MooseChef

> 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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Nicolas Anquetil

Re: Several modifications to MooseChef

> > 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

I knew somebody was going to say that.
And the next mail is ...

nicolas
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba-2

Re: Several modifications to MooseChef

In reply to this post by Nicolas Anquetil

Thanks, Nicolas.

On Mon, Dec 5, 2011 at 12:27 PM, Nicolas Anquetil
<[hidden email]> 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

--
www.tudorgirba.com

"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

Re: Several modifications to MooseChef

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Nicolas Anquetil

Re: Several modifications to MooseChef

> >> - 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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

simondenier

Re: Several modifications to MooseChef

In reply to this post by Nicolas Anquetil

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev