[Moose-dev] Re: Users of TDependencyQueries

On Nov 6, 2017, at 5:54 PM, Anne Etien <anne.etien(a)univ-lille1.fr&gt; 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(a)gmail.com&gt; a écrit : > > On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil > <nicolas.anquetil(a)inria.fr&gt; 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 > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev