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.
On Wed, Oct 11, 2017 at 3:03 PM, Nicolas Anquetil<firstname.lastname@example.org> wrote:
Hello,Hi,Is there still no alternative proposition?Again, today I got bitten by the fact that all FAMIXEntity subclassesdo not have the same API regarding Moose Query.I though that Moose-Query was a framework designed to simplified anduniformize the gathering of the associations inside a Moose model.Let's take an example: I have a class A. A children selector of Areturns instances of FAMIXSourcedEntity thanks to the containment treedefined through the #container pragma. To the children of class A, Ineed to ask the possible incomingAssociationTypes andoutgoingAssociationTypes. But, since FAMIXSourcedEntity does notimplement TEntityMetaLevelDependency (else the associations would haveit 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 andthese 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 theother methods of Moose-Query whose goal is to uniformize the entities?
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
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-- Cyril Ferlicothttps://ferlicot.frhttp://www.synectique.eu2 rue Jacques Prévert 01,59650 Villeneuve d'ascq France_______________________________________________Moose-dev mailing listMooseemail@example.com://www.list.inf.unibe.ch/listinfo/moose-dev
RMod team -- Inria Lille
Moose-dev mailing list