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@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
Le 6 nov. 2017 à 16:29, Cyril Ferlicot cyril.ferlicot@gmail.com a écrit :
On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil 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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"We are all great at making mistakes."