[Moose-dev] Re: Users of TDependencyQueries

On 11 Oct 2017, at 15:14, Tudor Girba <tudor(a)tudorgirba.com&gt; 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 <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). > > 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&gt; 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 >> >> > > -- > 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 -- 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