Smalltalk › Frameworks & Tools › Moose

Users of TDependencyQueries

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

CyrilFerlicot

Users of TDependencyQueries

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

Anne Etien

Re: Users of TDependencyQueries

> Le 10 oct. 2017 à 15:36, Cyril Ferlicot <[hidden email]> 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
> [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

CyrilFerlicot

Re: Users of TDependencyQueries

On Tue, Oct 10, 2017 at 3:45 PM, Anne Etien <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Anne Etien

Re: Users of TDependencyQueries

> Le 10 oct. 2017 à 15:54, Cyril Ferlicot <[hidden email]> a écrit :
>
> On Tue, Oct 10, 2017 at 3:45 PM, Anne Etien <[hidden email]> 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

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

>
>> Anne
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> 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
> [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

CyrilFerlicot

Re: Users of TDependencyQueries

On Tue, Oct 10, 2017 at 4:00 PM, Anne Etien <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Anne Etien

Re: Users of TDependencyQueries

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 <[hidden email]> a écrit :
>
> On Tue, Oct 10, 2017 at 4:00 PM, Anne Etien <[hidden email]> 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
>> [hidden email]
>> 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
> [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

CyrilFerlicot

Re: Users of TDependencyQueries

On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Anne Etien

Re: Users of TDependencyQueries

> Le 10 oct. 2017 à 16:52, Cyril Ferlicot <[hidden email]> a écrit :
>
> On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien <[hidden email]> 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.

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

Sorry, I am not familiar with shouldNotImplement. If it does the job, why not.

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

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.

>
> Thank you for the informations! :)

It was my pleasure :)

Anne

>
>> Anne
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> 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
> [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

CyrilFerlicot

Re: Users of TDependencyQueries

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
> [hidden email]
> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

signature.asc (836 bytes) Download Attachment

Nicolas Anquetil

Re: Users of TDependencyQueries

In reply to this post by CyrilFerlicot

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 <[hidden email]> 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
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>

--
Nicolas Anquetil
RMod team -- Inria Lille

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

Tudor Girba-2

Re: Users of TDependencyQueries

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 <[hidden email]> 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:
>> On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien <[hidden email]> 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
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>>
>
> --
> Nicolas Anquetil
> RMod team -- Inria Lille
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"No matter how many recipes we know, we still value a chef."

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

CyrilFerlicot

Re: Users of TDependencyQueries

In reply to this post by Nicolas Anquetil

On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil
<[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Stéphane Ducasse

Re: Users of TDependencyQueries

In reply to this post by Tudor Girba-2

+1 :)

On 11 Oct 2017, at 15:14, Tudor Girba <[hidden email]> wrote:

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 <[hidden email]> 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:
On Tue, Oct 10, 2017 at 4:24 PM, Anne Etien <[hidden email]> 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
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

--
Nicolas Anquetil
RMod team -- Inria Lille

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

--
www.tudorgirba.com
www.feenk.com

"No matter how many recipes we know, we still value a chef."

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

--------------------------------------------

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

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

CyrilFerlicot

Re: Users of TDependencyQueries

In reply to this post by Nicolas Anquetil

On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil
<[hidden email]> wrote:

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?

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

Anne Etien

Re: Users of TDependencyQueries

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 <[hidden email]> a écrit :

On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil
<[hidden email]> 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
[hidden email]
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
[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

Tudor Girba-2

Re: Users of TDependencyQueries

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 <[hidden email]> 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
>> Le 6 nov. 2017 à 16:29, Cyril Ferlicot <[hidden email]> a écrit :
>>
>> On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil
>> <[hidden email]> 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
>>> [hidden email]
>>> 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
>> [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

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."

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

CyrilFerlicot

Re: Users of TDependencyQueries

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
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

signature.asc (836 bytes) Download Attachment

Anne Etien

Re: Users of TDependencyQueries

Le 6 nov. 2017 à 18:24, Cyril Ferlicot D. <[hidden email]> a écrit :

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?

Yes.

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
[hidden email]
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
[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

CyrilFerlicot

Re: Users of TDependencyQueries

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
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

signature.asc (836 bytes) Download Attachment

Anne Etien

Re: Users of TDependencyQueries

> Le 6 nov. 2017 à 18:40, Cyril Ferlicot D. <[hidden email]> a écrit :
>
> 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.

Not understood the answer.

Anne

>
>> Anne
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> 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
> [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