12 Oct
2017
12 Oct
'17
10:55 a.m.
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
15 Oct
15 Oct
7:53 p.m.
New subject: 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
8:24 p.m.
New subject: 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
23 Oct
23 Oct
3:44 p.m.
Hi,
Le 12 oct. 2017 à 10:55, Cyril Ferlicot
<cyril.ferlicot(a)gmail.com> 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
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
2371
days inactive
2382
days old
3 comments
4 participants
participants (4)
-
Anne Etien -
Cyril Ferlicot -
Cyril Ferlicot D.
-
Nicolas Anquetil