Management of #queryAll{Direction}Associations (complete one)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Management of #queryAll{Direction}Associations (complete one)

CyrilFerlicot
Hi!

Sorry for my previous incomplete mail. I missclicked. Here is the full one:

I have some improvements I would like to make to Moose query and I
would like your approuval.

First. Currently there is:
- #queryAllOutgoing and #queryAllOutgoingAssociations to query all the
outgoing associations of the receiver
- #queryAllIncoming and #queryAllIncomingAssociations to query all the
incoming associations of the receiver

#queryAll{Direction} is based on the meta-model properties while
#queryAll{Direction}Associations seems to be more empirical.

See:

queryAllOutgoingAssociations
^ self queryStaticOutgoingAssociations
    addAll: self queryAllOutgoingInvocations;
    yourself

I propose two changes:
- Remove the empirical implementation to use only the one based on the
meta-model
- Deprecate #queryAllIncoming and #queryAllOutgoing. I think
#queryAllIncomingAssociations is a better name, but I can change my
mine if you have a different opinion on that.

Second. To query all the in/out associations with the method based on
the meta-models, there is the use of "FAMIXAssociation
withAllSubclassesDo:" to iterate on the associations and do the
queries for all of them.

I have three problems with that:
- This is not efficient. If an entity can have only 2 incoming
associations it will still try the queries for all the associations in
the image
- This has a role in the circular dependency between FAMIX-Core and
Moose-Query packages because we reference FAMIXAssociation
- If one day we create another project from FAME to represent
something that is not a software model, we will maybe not have
FAMIXAssociation but we might still have associations. And Moose-Query
could still be useful on this project.

I propose to add to TEntityMetaLevelDependency two methods:

allOutgoingAssociationTypes
    ^ (self allChildrenTypes flatCollectAsSet: #outgoingAssociationTypes)
        addAll: self outgoingAssociationTypes;
        yourself

and

allIncomingAssociationTypes
    ^ (self allChildrenTypes flatCollectAsSet: #incomingAssociationTypes)
        addAll: self incomingAssociationTypes;
        yourself


Thus the entities will be able to return the associations they and
their children can have.

Then we can replace "FAMIXAssociation withAllSubclassesDo:" by "(self
strategy allAssociationTypesFor: anEntity)
do:" where the strategy is a MooseQuery{Direction}DirectionStrategy
that will call either #allIncomingAssociationTypes or
#allOutgoingAssociationTypes.

I have an image with all those changes and all the tests of
Moose-Query and Moose-Chef are green.

I am waiting your opinion on this changes.

Have a nice day.

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management of #queryAll{Direction}Associations (complete one)

Nicolas Anquetil
Hi,

I could not find any queryAllOutgoing (on a moose5 image, I " lost"  my
computer last week, and did not recover it fully yet, so no recent moose
image).

Did you mean queryAllOutgoingDependencies ?

If so:

- queryStaticOutgoingAssociations, returns all association that can be
statically resolved in Pharo, i.e. Accesses, references, and inheritances

- queryAllOutgoingInvocations is quite obvious. Note that in pharo they
cannot be resolved statically (hence the candidates field of the
invocations)

- queryAllOutgoingAssociations, is a combination of all associations:
the "static"  ones + invocations

- finally, queryAllOutgoingDependencies, gathers all dependencies, even
those not modeled as associations: for exemple, the declaredType of the
variables and the functions

So each one of these return a different thing


For the un-efficient implementation to query all the in/out
associations, it seems like a good idea to improve it.
However, I would advocate against introducing new traits in Moose.
Traits tie us very much to Pharo. This is a problem if we plan to move
moose models to gemstone for example...

nicolas

On 12/10/2017 10:55, Cyril Ferlicot wrote:

> Hi!
>
> Sorry for my previous incomplete mail. I missclicked. Here is the full one:
>
> I have some improvements I would like to make to Moose query and I
> would like your approuval.
>
> First. Currently there is:
> - #queryAllOutgoing and #queryAllOutgoingAssociations to query all the
> outgoing associations of the receiver
> - #queryAllIncoming and #queryAllIncomingAssociations to query all the
> incoming associations of the receiver
>
> #queryAll{Direction} is based on the meta-model properties while
> #queryAll{Direction}Associations seems to be more empirical.
>
> See:
>
> queryAllOutgoingAssociations
> ^ self queryStaticOutgoingAssociations
>      addAll: self queryAllOutgoingInvocations;
>      yourself
>
> I propose two changes:
> - Remove the empirical implementation to use only the one based on the
> meta-model
> - Deprecate #queryAllIncoming and #queryAllOutgoing. I think
> #queryAllIncomingAssociations is a better name, but I can change my
> mine if you have a different opinion on that.
>
> Second. To query all the in/out associations with the method based on
> the meta-models, there is the use of "FAMIXAssociation
> withAllSubclassesDo:" to iterate on the associations and do the
> queries for all of them.
>
> I have three problems with that:
> - This is not efficient. If an entity can have only 2 incoming
> associations it will still try the queries for all the associations in
> the image
> - This has a role in the circular dependency between FAMIX-Core and
> Moose-Query packages because we reference FAMIXAssociation
> - If one day we create another project from FAME to represent
> something that is not a software model, we will maybe not have
> FAMIXAssociation but we might still have associations. And Moose-Query
> could still be useful on this project.
>
> I propose to add to TEntityMetaLevelDependency two methods:
>
> allOutgoingAssociationTypes
>      ^ (self allChildrenTypes flatCollectAsSet: #outgoingAssociationTypes)
>          addAll: self outgoingAssociationTypes;
>          yourself
>
> and
>
> allIncomingAssociationTypes
>      ^ (self allChildrenTypes flatCollectAsSet: #incomingAssociationTypes)
>          addAll: self incomingAssociationTypes;
>          yourself
>
>
> Thus the entities will be able to return the associations they and
> their children can have.
>
> Then we can replace "FAMIXAssociation withAllSubclassesDo:" by "(self
> strategy allAssociationTypesFor: anEntity)
> do:" where the strategy is a MooseQuery{Direction}DirectionStrategy
> that will call either #allIncomingAssociationTypes or
> #allOutgoingAssociationTypes.
>
> I have an image with all those changes and all the tests of
> Moose-Query and Moose-Chef are green.
>
> I am waiting your opinion on this changes.
>
> Have a nice day.
>

--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Management of #queryAll{Direction}Associations (complete one)

CyrilFerlicot
Le 15/10/2017 à 19:53, Nicolas Anquetil a écrit :
> Hi,
>
> I could not find any queryAllOutgoing (on a moose5 image, I " lost"  my
> computer last week, and did not recover it fully yet, so no recent moose
> image).
>
> Did you mean queryAllOutgoingDependencies ?
>

Hi,

No. #queryAll{Direction} was introduced in Moose 6 with MooseQuery.

> If so:
>
> - queryStaticOutgoingAssociations, returns all association that can be
> statically resolved in Pharo, i.e. Accesses, references, and inheritances
>
> - queryAllOutgoingInvocations is quite obvious. Note that in pharo they
> cannot be resolved statically (hence the candidates field of the
> invocations)
>
> - queryAllOutgoingAssociations, is a combination of all associations:
> the "static"  ones + invocations
>
This is the goal of #queryAll{Direction}

> - finally, queryAllOutgoingDependencies, gathers all dependencies, even
> those not modeled as associations: for exemple, the declaredType of the
> variables and the functions
>
> So each one of these return a different thing
>
>
> For the un-efficient implementation to query all the in/out
> associations, it seems like a good idea to improve it.
> However, I would advocate against introducing new traits in Moose.
> Traits tie us very much to Pharo. This is a problem if we plan to move
> moose models to gemstone for example...
>
My solution will not introduce new Trait to Moose. Also if we use
Gemstone I think we will win more time by changing Metacello to flatten
Trait in Gemstone during the loading than to remove Traits.

> nicolas
>
>


--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France


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

signature.asc (836 bytes) Download Attachment