Smalltalk › Frameworks & Tools › Moose

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

CyrilFerlicot

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

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

Nicolas Anquetil

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

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

CyrilFerlicot

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

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

Anne Etien

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

In reply to this post by CyrilFerlicot

Hi,

> Le 12 oct. 2017 à 10:55, Cyril Ferlicot <[hidden email]> a écrit :
>
> 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.

As far as I understood when we discussed in Maribore, it can be relevant to have specific associations to earn time. But perhaps cache can bring a solution. I don’t know if the solution you propose is time consuming or not.
>
> 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 agree with you, we need a method to compute the Association Types the class of self is source (rest. target) of. And not try all the association to know if the class is source or target of this association.

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

Moose-Query is already dependent of FAMIX-Core, no?

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

I don’t really see how it works in practice. I think that #outgoingAssociationTypes is missing in your explanation.

#privateOutgoingAssociationTypes
self allDeclaredProperties select: [ :fm3Prop | | ic | ic := fm3Prop type implementingClass.
ic notNil and: [ic inheritsFrom: FAMIXAssociation ] ]

And here, I don’t manage the direction yet.

Why you don’t do the same thing than for allChildrenTypes?

Code is missing for me to fully approve what you are doing.

In other words:
1. I agree about the idea that we have to compute for each metaclass its incoming / outgoing associations
2. I am not enough data to approve your code
3. you can come on Friday morning to the Moose Dojo and Pharo sprint to make the changes together if you want.

Anne

> 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

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