10 Oct
2017
10 Oct
'17
3:36 p.m.
Hi,
Currently Moose-Query works with Traits.
There is :
- TDependencyQueries containing all the query system and the common
queries such as #queryIncomingAccesses
- TOODependencyQueries using TDependencyQueries and adding the method
specific to OO entities (mostly inheritance queries)
The users of TDependencyQueries are:
- TOODependencyQueries
- FAMIXAnnotationInstance
- FAMIXAnnotationInstanceAttribute
- FAMIXSourceAnchor
The users of TOODependencyQueries are:
- FAMIXNamedEntity
I think it would make sense to move TDependencyQueries to FAMIXEntity.
FAMIXEntity has all the API needed to the queries and it would help
with the consistancy. For example I think that all famix entities
should be able to answer to "queryAllIncomingAssociations". It would
felp making more generic tools.
What do you think? Does that bother someone?
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
10 Oct
10 Oct
3:45 p.m.
Le 10 oct. 2017 à 15:36, Cyril Ferlicot
<cyril.ferlicot(a)gmail.com> a écrit :
Hi,
Currently Moose-Query works with Traits.
There is :
- TDependencyQueries containing all the query system and the common
queries such as #queryIncomingAccesses
- TOODependencyQueries using TDependencyQueries and adding the method
specific to OO entities (mostly inheritance queries)
The users of TDependencyQueries are:
- TOODependencyQueries
- FAMIXAnnotationInstance
- FAMIXAnnotationInstanceAttribute
- FAMIXSourceAnchor
The users of TOODependencyQueries are:
- FAMIXNamedEntity
I think it would make sense to move TDependencyQueries to FAMIXEntity.
No, it does not make sense.
By putting TOODependencyQueries to FAMIXNamedEntity and not FAMIXEntity, the idea was to
query only non association entity. It was the only way to do it.
If you look at the users of TDependencyQueries, it is all the non association entity that
have no name.
If you do the change you suggest, you will be able to ask queryAllIncomingAssociations on
a FAMIXInvocation, what makes no sense.
So the only way to do it is to say that the entity should not inherits from
FAMIXAssociation.
Anne
FAMIXEntity has all the API needed to the queries and
it would help
with the consistancy. For example I think that all famix entities
should be able to answer to "queryAllIncomingAssociations". It would
felp making more generic tools.
What do you think? Does that bother someone?
--
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
3:54 p.m.
On Tue, Oct 10, 2017 at 3:45 PM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote:
No, it does not make sense.
By putting TOODependencyQueries to FAMIXNamedEntity and not FAMIXEntity, the idea was to
query only non association entity. It was the only way to do it.
If you look at the users of TDependencyQueries, it is all the non association entity that
have no name.
If you do the change you suggest, you will be able to ask queryAllIncomingAssociations on
a FAMIXInvocation, what makes no sense.
So the only way to do it is to say that the entity should not inherits from
FAMIXAssociation.
Would it not be less constraining to make FAMIXEntity use
TDependencyQueries and to override #query:with: (and the other query
methods not using this one) to throw an error?
Because now each time we implement an entity that is not named we need
to think to add the trait and we cannot expect all famix entities to
be able to answer to methods like #queryAllIncomingAssociations
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
4 p.m.
Le 10 oct. 2017 à 15:54, Cyril Ferlicot
<cyril.ferlicot(a)gmail.com> a écrit :
On Tue, Oct 10, 2017 at 3:45 PM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote:
I don’t understand the end of the last sentence.
Not so sure, because as it is currently done, FAMIXComment can not answer to method like
queryAllIncomingAssociations, because it is not linked to other entities through any
association just a container relationship that is not an association. It can be the case
of other entities (I have no idea which one).
Anne
No, it does not make sense.
By putting TOODependencyQueries to FAMIXNamedEntity and not FAMIXEntity, the idea was to
query only non association entity. It was the only way to do it.
If you look at the users of TDependencyQueries, it is all the non association entity that
have no name.
If you do the change you suggest, you will be able to ask queryAllIncomingAssociations on
a FAMIXInvocation, what makes no sense.
So the only way to do it is to say that the entity should not inherits from
FAMIXAssociation.
Would it not be less constraining to make FAMIXEntity use
TDependencyQueries and to override #query:with: (and the other query
methods not using this one) to throw an error?
Because now each time we implement an entity that is not named we need
to think to add the trait and we cannot expect all famix entities to
be able to answer to methods like #queryAllIncomingAssociations Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
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
4:09 p.m.
On Tue, Oct 10, 2017 at 4:00 PM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote:
I don’t understand the end of the last sentence.
I mean that if we do that, it will be easier to implement new
FAMIXEntity and/or to adapt existing models to works with Moose-Query.
Also, if all FAMIXEntity does not use the Trait, we cannot
#queryAllIncomingAssociations in Tools manipulating FAMIXEntities
without the fear that it will break because one find of entity might
not use the Trait.
Not so sure, because as it is currently done,
FAMIXComment can not answer to method like queryAllIncomingAssociations, because it is not
linked to other entities through any association just a container relationship that is not
an association. It can be the case of other entities (I have no idea which one).
What is the problem if we ask the incoming association to an entity
that has none? Currently FAMIXType understand
#queryOutgoingInvocations but it will never return one since it is not
a Behavioural entity.
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
4:24 p.m.
I was explaining to you the design. I thought it was the only way, but the only way in my
logic, whereas other may exist ;o) So perhaps your idea of overwriting the methods can be
good. But it has to be done.
I currently don’t know what is the behavior of ask the incoming association to an entity
that has none.
I think that it can be good that you investigate this point before doing any change. And
then consequently modify the code to correct or not this behavior. It can be here an error
in the design, I don’t know.
But perhaps also for performance reasons, it can be good, that such query can not be asked
to associations. Because here you know that in any case, it does not make sense.
If you can modify the code to have the same behavior (or better), no soucy for me. Just be
aware of all of this (what was not the case initially). I think it is all the reasons
explaining the design. But perhaps I forgot some :p
Anne
Le 10 oct. 2017 à 16:09, Cyril Ferlicot
<cyril.ferlicot(a)gmail.com> a écrit :
On Tue, Oct 10, 2017 at 4:00 PM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote:
I don’t understand the end of the last sentence.
I mean that if we do that, it will be easier to implement new
FAMIXEntity and/or to adapt existing models to works with Moose-Query.
Also, if all FAMIXEntity does not use the Trait, we cannot
#queryAllIncomingAssociations in Tools manipulating FAMIXEntities
without the fear that it will break because one find of entity might
not use the Trait.
Not so sure, because as it is currently done,
FAMIXComment can not answer to method like queryAllIncomingAssociations, because it is not
linked to other entities through any association just a container relationship that is not
an association. It can be the case of other entities (I have no idea which one).
What is the problem if we ask the incoming association to an entity
that has none? Currently FAMIXType understand
#queryOutgoingInvocations but it will never return one since it is not
a Behavioural entity.
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
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
4:52 p.m.
On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote:
I was explaining to you the design. I thought it was
the only way, but the only way in my logic, whereas other may exist ;o) So perhaps your
idea of overwriting the methods can be good. But it has to be done.
Ok :)
If nobody see a problem with my logic I am willing to do it.
I currently don’t know what is the behavior of ask the
incoming association to an entity that has none.
I think that it can be good that you investigate this point before doing any change. And
then consequently modify the code to correct or not this behavior. It can be here an error
in the design, I don’t know.
Currently it will return an empty query result. The best example is
the FAMIXSourceAnchor that understand the queries but always return an
empty query result.
But perhaps also for performance reasons, it can be
good, that such query can not be asked to associations. Because here you know that in any
case, it does not make sense.
I totally agree with you on the point that we should not be able to
query associations. If we query an association, we have a problem in
the model. Yann propose to use #shouldNotImplement in the
associations.
If you can modify the code to have the same behavior
(or better), no soucy for me. Just be aware of all of this (what was not the case
initially). I think it is all the reasons explaining the design. But perhaps I forgot some
:p
I want to improve the situation and I knew there was probably a reason
to not implement it directly on FAMIXEntity, this is why I asked on
the ML. :)
Now that I know the reason I think it is safe to move the Trait up and
to override the methods of FAMIXAssociations. If there is no other
reason someone might think of, I'll do the change and add some
comments to explain it.
Thank you for the informations! :)
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
6:22 p.m.
Le 10 oct. 2017 à 16:52, Cyril Ferlicot
<cyril.ferlicot(a)gmail.com> a écrit :
On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote:
Is it the expected behavior? Or do we want that we are not able to ask for outgoing
association if the entity is not source of an association. So for example, instead of
looking for outgoing association of a never source entity, it directly returns an empty
result. Perhaps we could have gain in performance, but be careful with the recursive
query. Indeed, it is not because an entity is never a source that its children are not. So
I don’t know but perhaps we can think to the question before changing.
I was explaining to you the design. I thought it
was the only way, but the only way in my logic, whereas other may exist ;o) So perhaps
your idea of overwriting the methods can be good. But it has to be done.
Ok :)
If nobody see a problem with my logic I am willing to do it.
I currently don’t know what is the behavior of
ask the incoming association to an entity that has none.
I think that it can be good that you investigate this point before doing any change. And
then consequently modify the code to correct or not this behavior. It can be here an error
in the design, I don’t know.
Currently it will return an empty query result. The best example is
the FAMIXSourceAnchor that understand the queries but always return an
empty query result. But perhaps also for performance reasons, it can
be good, that such query can not be asked to associations. Because here you know that in
any case, it does not make sense.
I totally agree with you on the point that we should not be able to
query associations. If we query an association, we have a problem in
the model. Yann propose to use #shouldNotImplement in the
associations. If you can modify the code to have the same
behavior (or better), no soucy for me. Just be aware of all of this (what was not the case
initially). I think it is all the reasons explaining the design. But perhaps I forgot some
:p
I want to improve the situation and I knew there was probably a reason
to not implement it directly on FAMIXEntity, this is why I asked on
the ML. :)
Now that I know the reason I think it is safe to move the Trait up and
to override the methods of FAMIXAssociations. If there is no other
reason someone might think of, I'll do the change and add some
comments to explain it.
Thank you for the informations! :)
It was my pleasure :)
Anne
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
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
8:41 p.m.
Le 10/10/2017 à 18:22, Anne Etien a écrit :
Is it the expected behavior? Or do we want that we are not able to ask for outgoing
association if the entity is not source of an association. So for example, instead of
looking for outgoing association of a never source entity, it directly returns an empty
result. Perhaps we could have gain in performance, but be careful with the recursive
query. Indeed, it is not because an entity is never a source that its children are not. So
I don’t know but perhaps we can think to the question before changing.
I think this is the expected behaviour because if you extend a class for
another language and if you add a property referencing an association
you want it to be collected.
Later I may plan to make Famix configurable enough to be able to load
only what is needed for each languages. Maybe at that time we could add
some optimisations based on each languages. But for now I think Famix is
not modular enough.
But maybe I am wrong, if someone has an idea to optimize with the
current famix I would be glad to hear it!
Also, FAMIXSourceAnchor already override some methods to return empty
query results.
Sorry, I am not familiar with shouldNotImplement. If it does the job, why not.
It is just a method you can call and it will open a debugger with an
error saying that the class should not implement the method. If we are
in that case, it means we use the API of the class in the wrong way.
Wait, one question, that I have and I don’t remember the answer. Why FAMIXNamedEntity is
a user of TOODependencyQueries and not of TDependencyQueries and thus why not just
FAMIXType is a user of TOODependencyQueries? Depending on the answer to this question, you
can push up TDependencyQueries or TOODependencyQueries to FAMIXEntity.
I don't have the answer to this question :)
This is also one thing I find weird.
In the beginning TOODependencyQueries was implemented on
FAMIXNamedEntity, FAMIXType and FAMIXBehivouralEntity. Since the last
two inherits from the former, I removed it.
I was planning to talk about it later. I have other refactorings planed
but I do it step by step :)
It was my pleasure :)
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
11 Oct
11 Oct
3:03 p.m.
Hello,
it is generally a bad idea to use inheritance for reuse instead of
subtyping. It is a sure recipe to future problems.
So what you are proposing would work (for example inheriting methods and
overriding them to raise errors), but it is a hack that will hit back
whoever maintains the code in a few years/months.
I very strongly vote against your proposition. We need to think harder
and longer to find an appropriate solution that will both respect the
"real nature" of things (it does not make sense to ask a comment or an
association allIncomingAccesses)
In the past we had problems with relations made to entities that were
not the right one (for example using references for the worng thing).
nicolas
On 10/10/2017 16:52, Cyril Ferlicot wrote:
On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien
<anne.etien(a)univ-lille1.fr> wrote:
--
Nicolas Anquetil
RMod team -- Inria Lille
I was explaining to you the design. I thought it
was the only way, but the only way in my logic, whereas other may exist ;o) So perhaps
your idea of overwriting the methods can be good. But it has to be done.
Ok :)
If nobody see a problem with my logic I am willing to do it.
I currently don’t know what is the behavior of
ask the incoming association to an entity that has none.
I think that it can be good that you investigate this point before doing any change. And
then consequently modify the code to correct or not this behavior. It can be here an error
in the design, I don’t know.
Currently it will return an empty query result. The best example is
the FAMIXSourceAnchor that understand the queries but always return an
empty query result.
But perhaps also for performance reasons, it can
be good, that such query can not be asked to associations. Because here you know that in
any case, it does not make sense.
I totally agree with you on the point that we should not be able to
query associations. If we query an association, we have a problem in
the model. Yann propose to use #shouldNotImplement in the
associations.
If you can modify the code to have the same
behavior (or better), no soucy for me. Just be aware of all of this (what was not the case
initially). I think it is all the reasons explaining the design. But perhaps I forgot some
:p
I want to improve the situation and I knew there was probably a reason
to not implement it directly on FAMIXEntity, this is why I asked on
the ML. :)
Now that I know the reason I think it is safe to move the Trait up and
to override the methods of FAMIXAssociations. If there is no other
reason someone might think of, I'll do the change and add some
comments to explain it.
Thank you for the informations! :)
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
3:14 p.m.
Hi,
I do not have much time to go into details, but I strongly agree with Nicolas.
Doru
On Oct 11, 2017, at 3:03 PM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr> wrote:
Hello,
it is generally a bad idea to use inheritance for reuse instead of subtyping. It is a
sure recipe to future problems.
So what you are proposing would work (for example inheriting methods and overriding them
to raise errors), but it is a hack that will hit back whoever maintains the code in a few
years/months.
I very strongly vote against your proposition. We need to think harder and longer to find
an appropriate solution that will both respect the "real nature" of things (it
does not make sense to ask a comment or an association allIncomingAccesses)
In the past we had problems with relations made to entities that were not the right one
(for example using references for the worng thing).
nicolas
On 10/10/2017 16:52, Cyril Ferlicot wrote:
--
www.tudorgirba.com
www.feenk.com
"No matter how many recipes we know, we still value a chef."
On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien
<anne.etien(a)univ-lille1.fr> wrote:
--
Nicolas Anquetil
RMod team -- Inria Lille
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev I was explaining to you the design. I thought it
was the only way, but the only way in my logic, whereas other may exist ;o) So perhaps
your idea of overwriting the methods can be good. But it has to be done.
Ok :)
If nobody see a problem with my logic I am willing to do it.
I currently don’t know what is the behavior of
ask the incoming association to an entity that has none.
I think that it can be good that you investigate this point before doing any change. And
then consequently modify the code to correct or not this behavior. It can be here an error
in the design, I don’t know.
Currently it will return an empty query result. The best example is
the FAMIXSourceAnchor that understand the queries but always return an
empty query result.
But perhaps also for performance reasons, it can
be good, that such query can not be asked to associations. Because here you know that in
any case, it does not make sense.
I totally agree with you on the point that we should not be able to
query associations. If we query an association, we have a problem in
the model. Yann propose to use #shouldNotImplement in the
associations.
If you can modify the code to have the same
behavior (or better), no soucy for me. Just be aware of all of this (what was not the case
initially). I think it is all the reasons explaining the design. But perhaps I forgot some
:p
I want to improve the situation and I knew there was probably a reason
to not implement it directly on FAMIXEntity, this is why I asked on
the ML. :)
Now that I know the reason I think it is safe to move the Trait up and
to override the methods of FAMIXAssociations. If there is no other
reason someone might think of, I'll do the change and add some
comments to explain it.
Thank you for the informations! :)
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
8:57 p.m.
+1 :)
On 11 Oct 2017, at 15:14, Tudor Girba
<tudor(a)tudorgirba.com> wrote:
Hi,
I do not have much time to go into details, but I strongly agree with Nicolas.
Doru
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
On Oct 11, 2017, at 3:03 PM, Nicolas Anquetil
<Nicolas.Anquetil(a)inria.fr> wrote:
Hello,
it is generally a bad idea to use inheritance for reuse instead of subtyping. It is a
sure recipe to future problems.
So what you are proposing would work (for example inheriting methods and overriding them
to raise errors), but it is a hack that will hit back whoever maintains the code in a few
years/months.
I very strongly vote against your proposition. We need to think harder and longer to find
an appropriate solution that will both respect the "real nature" of things (it
does not make sense to ask a comment or an association allIncomingAccesses)
In the past we had problems with relations made to entities that were not the right one
(for example using references for the worng thing).
nicolas
On 10/10/2017 16:52, Cyril Ferlicot wrote:
--
www.tudorgirba.com
www.feenk.com
"No matter how many recipes we know, we still value a chef."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien
<anne.etien(a)univ-lille1.fr> wrote:
--
Nicolas Anquetil
RMod team -- Inria Lille
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev I was explaining to you the design. I thought it
was the only way, but the only way in my logic, whereas other may exist ;o) So perhaps
your idea of overwriting the methods can be good. But it has to be done.
Ok :)
If nobody see a problem with my logic I am willing to do it.
I currently don’t know what is the behavior of
ask the incoming association to an entity that has none.
I think that it can be good that you investigate this point before doing any change. And
then consequently modify the code to correct or not this behavior. It can be here an error
in the design, I don’t know.
Currently it will return an empty query result. The best example is
the FAMIXSourceAnchor that understand the queries but always return an
empty query result.
But perhaps also for performance reasons, it can
be good, that such query can not be asked to associations. Because here you know that in
any case, it does not make sense.
I totally agree with you on the point that we should not be able to
query associations. If we query an association, we have a problem in
the model. Yann propose to use #shouldNotImplement in the
associations.
If you can modify the code to have the same
behavior (or better), no soucy for me. Just be aware of all of this (what was not the case
initially). I think it is all the reasons explaining the design. But perhaps I forgot some
:p
I want to improve the situation and I knew there was probably a reason
to not implement it directly on FAMIXEntity, this is why I asked on
the ML. :)
Now that I know the reason I think it is safe to move the Trait up and
to override the methods of FAMIXAssociations. If there is no other
reason someone might think of, I'll do the change and add some
comments to explain it.
Thank you for the informations! :)
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
3:26 p.m.
On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil
<nicolas.anquetil(a)inria.fr> wrote:
Hello,
it is generally a bad idea to use inheritance for reuse instead of
subtyping. It is a sure recipe to future problems.
So what you are proposing would work (for example inheriting methods and
overriding them to raise errors), but it is a hack that will hit back
whoever maintains the code in a few years/months.
I very strongly vote against your proposition. We need to think harder and
longer to find an appropriate solution that will both respect the "real
nature" of things (it does not make sense to ask a comment or an association
allIncomingAccesses)
In the past we had problems with relations made to entities that were not
the right one (for example using references for the worng thing).
I understand your concern but currently it already works this way, but
not for all entities.
FAMIXType understand #queryIncomingInvocations and
#queryOutgoingInvocations but it cannot return something because it
does not have any invocation in its properties.
The other solution would be to change the Trait to get only the query
system without any reference to FAMIXInvocation, FAMIXReference,
FAMIXInheritance, FAMIXAccess. Thus we would remove all
#query{Direction}{Association} from the trait and we would add them
directly on the entities concerned by extension. Because either we
accept that all the entities understand those methods or only the
entities that *can* return something understand them.
For now we are in between. Not all entities understand those methods
but some on them understand methods they have nothing to return for
except an empty result and this situation make it complicated to build
generic tools.
I wait you answer about this.
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
6 Nov
6 Nov
4:29 p.m.
On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil
<nicolas.anquetil(a)inria.fr> wrote:
Hello,
it is generally a bad idea to use inheritance for reuse instead of
subtyping. It is a sure recipe to future problems.
So what you are proposing would work (for example inheriting methods and
overriding them to raise errors), but it is a hack that will hit back
whoever maintains the code in a few years/months.
I very strongly vote against your proposition. We need to think harder and
longer to find an appropriate solution that will both respect the "real
nature" of things (it does not make sense to ask a comment or an association
allIncomingAccesses)
In the past we had problems with relations made to entities that were not
the right one (for example using references for the worng thing).
Hi,
Is there still no alternative proposition?
Again, today I got bitten by the fact that all FAMIXEntity subclasses
do not have the same API regarding Moose Query.
I though that Moose-Query was a framework designed to simplified and
uniformize the gathering of the associations inside a Moose model.
Let's take an example: I have a class A. A children selector of A
returns instances of FAMIXSourcedEntity thanks to the containment tree
defined through the #container pragma. To the children of class A, I
need to ask the possible incomingAssociationTypes and
outgoingAssociationTypes. But, since FAMIXSourcedEntity does not
implement TEntityMetaLevelDependency (else the associations would have
it too), the Moose-Query algorithm does not works.
How should I manage the children that are FAMIXSourcedEntity? What should I do?
Why shouldn't we ensure that associations understand the navigation queries?
They already understand #children, #atScope:, #toScope:, #comments and
these associations should not understand neither of those methods.
However, they are in the current Moose version.
So, why shouldn't we add #queryAllIncoming, #queryAllOutgoing and the
other methods of Moose-Query whose goal is to uniformize the entities?
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
5:54 p.m.
Cyril,
I already said that to you. I think that the solution is to introduced a new class in the
hierarchy just below FamixSourcedEntity. Let call it FamixNonAssociationEntity. The
Associations obviously won’t inherit from it but all the other sourced entity yes. And
each time you are expecting a FamixSourcedEntity, I am sure that in fact you are expecting
a FamixNonAssociationEntity. It is this FamixNonAssociationEntity that implements
TEntityMetaLevelDependency.
It is really more realistic like this.
Anne
Le 6 nov. 2017 à 16:29, Cyril Ferlicot
<cyril.ferlicot(a)gmail.com> a écrit :
On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil
<nicolas.anquetil(a)inria.fr <mailto:nicolas.anquetil@inria.fr>> wrote:
Hello,
it is generally a bad idea to use inheritance for reuse instead of
subtyping. It is a sure recipe to future problems.
So what you are proposing would work (for example inheriting methods and
overriding them to raise errors), but it is a hack that will hit back
whoever maintains the code in a few years/months.
I very strongly vote against your proposition. We need to think harder and
longer to find an appropriate solution that will both respect the "real
nature" of things (it does not make sense to ask a comment or an association
allIncomingAccesses)
In the past we had problems with relations made to entities that were not
the right one (for example using references for the worng thing).
Hi,
Is there still no alternative proposition?
Again, today I got bitten by the fact that all FAMIXEntity subclasses
do not have the same API regarding Moose Query.
I though that Moose-Query was a framework designed to simplified and
uniformize the gathering of the associations inside a Moose model.
Let's take an example: I have a class A. A children selector of A
returns instances of FAMIXSourcedEntity thanks to the containment tree
defined through the #container pragma. To the children of class A, I
need to ask the possible incomingAssociationTypes and
outgoingAssociationTypes. But, since FAMIXSourcedEntity does not
implement TEntityMetaLevelDependency (else the associations would have
it too), the Moose-Query algorithm does not works.
How should I manage the children that are FAMIXSourcedEntity? What should I do?
Why shouldn't we ensure that associations understand the navigation queries?
They already understand #children, #atScope:, #toScope:, #comments and
these associations should not understand neither of those methods.
However, they are in the current Moose version.
So, why shouldn't we add #queryAllIncoming, #queryAllOutgoing and the
other methods of Moose-Query whose goal is to uniformize the entities?
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
--
Cyril Ferlicot
https://ferlicot.fr <https://ferlicot.fr/>
http://www.synectique.eu <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 <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
6:02 p.m.
Hi,
The point of Traits is exactly to not require inheritance.
Why is it not good solution to add TEntityMetaLevelDependency to all classes that require
it regardless of the place in inheritance?
Cheers,
Doru
On Nov 6, 2017, at 5:54 PM, Anne Etien
<anne.etien(a)univ-lille1.fr> wrote:
Cyril,
I already said that to you. I think that the solution is to introduced a new class in the
hierarchy just below FamixSourcedEntity. Let call it FamixNonAssociationEntity. The
Associations obviously won’t inherit from it but all the other sourced entity yes. And
each time you are expecting a FamixSourcedEntity, I am sure that in fact you are expecting
a FamixNonAssociationEntity. It is this FamixNonAssociationEntity that implements
TEntityMetaLevelDependency.
It is really more realistic like this.
Anne
--
www.tudorgirba.com
www.feenk.com
"We are all great at making mistakes."
Le 6 nov. 2017 à 16:29, Cyril Ferlicot
<cyril.ferlicot(a)gmail.com> a écrit :
On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil
<nicolas.anquetil(a)inria.fr> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev Hello,
it is generally a bad idea to use inheritance for reuse instead of
subtyping. It is a sure recipe to future problems.
So what you are proposing would work (for example inheriting methods and
overriding them to raise errors), but it is a hack that will hit back
whoever maintains the code in a few years/months.
I very strongly vote against your proposition. We need to think harder and
longer to find an appropriate solution that will both respect the "real
nature" of things (it does not make sense to ask a comment or an association
allIncomingAccesses)
In the past we had problems with relations made to entities that were not
the right one (for example using references for the worng thing).
Hi,
Is there still no alternative proposition?
Again, today I got bitten by the fact that all FAMIXEntity subclasses
do not have the same API regarding Moose Query.
I though that Moose-Query was a framework designed to simplified and
uniformize the gathering of the associations inside a Moose model.
Let's take an example: I have a class A. A children selector of A
returns instances of FAMIXSourcedEntity thanks to the containment tree
defined through the #container pragma. To the children of class A, I
need to ask the possible incomingAssociationTypes and
outgoingAssociationTypes. But, since FAMIXSourcedEntity does not
implement TEntityMetaLevelDependency (else the associations would have
it too), the Moose-Query algorithm does not works.
How should I manage the children that are FAMIXSourcedEntity? What should I do?
Why shouldn't we ensure that associations understand the navigation queries?
They already understand #children, #atScope:, #toScope:, #comments and
these associations should not understand neither of those methods.
However, they are in the current Moose version.
So, why shouldn't we add #queryAllIncoming, #queryAllOutgoing and the
other methods of Moose-Query whose goal is to uniformize the entities?
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
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
6:24 p.m.
Le 06/11/2017 à 18:02, Tudor Girba a écrit :
Hi,
The point of Traits is exactly to not require inheritance.
Why is it not good solution to add TEntityMetaLevelDependency to all classes that require
it regardless of the place in inheritance?
My problem is that: I know that a children selector will return a
FAMIXSourcedEntity and I need to send some messages to
FAMIXSourcedEntity that are in the Trait. But FAMIXSourcedEntity cannot
use the Trait if we do not accept that the associations will also get
the Trait.
If we introduce this FAMIXNonAssociationEntity then we will move
#comments and #containerFiles to this entity? Also FAMIXFile>>entities
should point to FAMIXNonAssociationEntity?
But once again… Why an association car understand
#atScope:/#children/#parents (which are queries) and not #queryAllIncoming?
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"We are all great at making mistakes."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
6:36 p.m.
Le 6 nov. 2017 à 18:24, Cyril Ferlicot D.
<cyril.ferlicot(a)gmail.com> a écrit :
Le 06/11/2017 à 18:02, Tudor Girba a écrit :
Yes.
Hi,
The point of Traits is exactly to not require inheritance.
Why is it not good solution to add TEntityMetaLevelDependency to all classes that require
it regardless of the place in inheritance?
My problem is that: I know that a children selector will return a
FAMIXSourcedEntity and I need to send some messages to
FAMIXSourcedEntity that are in the Trait. But FAMIXSourcedEntity cannot
use the Trait if we do not accept that the associations will also get
the Trait.
If we introduce this FAMIXNonAssociationEntity then we will move
#comments and #containerFiles to this entity? Also FAMIXFile>>entities
should point to FAMIXNonAssociationEntity?
But once again… Why an association car understand
#atScope:/#children/#parents (which are queries) and not #queryAllIncoming?
I don’t remember why. Perhaps it is a design error.
I would have to make some test to have be sure. But no time to do it in the next two weeks
at least or even more. Sorry.
If you want, try to remove TMetaLevelDependencies in the traits used by
TAssociationMetaLevelDependency.
Anne
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"We are all great at making mistakes."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr <https://ferlicot.fr/>
http://www.synectique.eu <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 <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
<https://www.list.inf.unibe.ch/listinfo/moose-dev>
6:40 p.m.
Le 06/11/2017 à 18:36, Anne Etien a écrit :
I don’t remember why. Perhaps it is a design error.
I would have to make some test to have be sure. But no time to do it in
the next two weeks at least or even more. Sorry.
If you want, try to remove TMetaLevelDependencies in the traits used by
TAssociationMetaLevelDependency.
Those are not only in TAssociationMetaLevelDependency but also in
TMetaLevelDependencies used by FAMIXEntity.
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
7 p.m.
Le 6 nov. 2017 à 18:40, Cyril Ferlicot D.
<cyril.ferlicot(a)gmail.com> a écrit :
Le 06/11/2017 à 18:36, Anne Etien a écrit :
Not understood the answer.
Anne
I don’t remember why. Perhaps it is a design error.
I would have to make some test to have be sure. But no time to do it in
the next two weeks at least or even more. Sorry.
If you want, try to remove TMetaLevelDependencies in the traits used by
TAssociationMetaLevelDependency.
Those are not only in TAssociationMetaLevelDependency but also in
TMetaLevelDependencies used by FAMIXEntity. Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
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
7:03 p.m.
Le 06/11/2017 à 19:00, Anne Etien a écrit :
If we remove TMetaLevelDependencies from
TAssociationMetaLevelDependency, associations will still have
#children/#parents/#atScope:/#toScope:…
Or maybe I did not understood you last sentence on the previous mail.
Le 6 nov. 2017 à 18:40, Cyril Ferlicot D.
<cyril.ferlicot(a)gmail.com> a écrit :
Le 06/11/2017 à 18:36, Anne Etien a écrit :
Not understood the answer.
I don’t remember why. Perhaps it is a design error.
I would have to make some test to have be sure. But no time to do it in
the next two weeks at least or even more. Sorry.
If you want, try to remove TMetaLevelDependencies in the traits used by
TAssociationMetaLevelDependency.
Those are not only in TAssociationMetaLevelDependency but also in
TMetaLevelDependencies used by FAMIXEntity.
Anne
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Cyril Ferlicot
https://ferlicot.fr
http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
11 Nov
11 Nov
11:20 a.m.
On 06/11/2017 18:24, Cyril Ferlicot D. wrote:
Le 06/11/2017 à 18:02, Tudor Girba a écrit :
this is
wrong.
The problem actually comes from the fact that these methods are defined
at the FamixEntity level which is way to high in the inheritance hierarchy.
It does not make sense to ask the children of a sourceAnchor, nor its scope.
Same for FAMIXSourceLanguage
The problem is well known, we need some kind of "multiple-inheritance"
and hopefully, the Famix will provide it.
2 solutions:
- the best is the solution proposed by Anne, but it is a bot more work
- yours is a possible one if we believe the new Famix is coming real
soon and will be integrated in Moose immediately after
Reason tells me that we should not count for integration of newFamix in
Moose before sometime next year (maybe around pharo7.0 release ?)
So it would still be best to go with Anne's solution because history is
full of this-is-only-for-short-period-of-time solutions that lasted forever
(it is actually possible that the problems with children/... being too
high in the inheritance hierarchy stems from one of these decisions)
only my 2c
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
Hi,
The point of Traits is exactly to not require inheritance.
Why is it not good solution to add TEntityMetaLevelDependency to all classes that require
it regardless of the place in inheritance?
My problem is that: I know that a children selector will return a
FAMIXSourcedEntity and I need to send some messages to
FAMIXSourcedEntity that are in the Trait. But FAMIXSourcedEntity cannot
use the Trait if we do not accept that the associations will also get
the Trait.
If we introduce this FAMIXNonAssociationEntity then we will move
#comments and #containerFiles to this entity? Also FAMIXFile>>entities
should point to FAMIXNonAssociationEntity?
But once again… Why an association car understand
#atScope:/#children/#parents (which are queries) and not #queryAllIncoming?
2597
days inactive
2629
days old
21 comments
6 participants
participants (6)
-
Anne Etien -
Cyril Ferlicot -
Cyril Ferlicot D.
-
Nicolas Anquetil -
Stéphane Ducasse -
Tudor Girba