search

moosetechnology / Famix

An abstract representation of source code. Famix is generic and can describe applications in multiple programming languages.
MIT License
13 stars 23 forks source link

Reify type declarations as associations #121

Open badetitou opened 4 years ago

NicolasAnquetil commented 4 years ago

description of the issue? Not clear what is meant

jecisc commented 4 years ago

This was to reify type declarations as associations

NicolasAnquetil commented 4 years ago

Ah yes. Reification is needed. But creating an object for this could be costly in memory. In the old query system, the queries created "fake reification" on the fly. This could be a better solution ?

jecisc commented 4 years ago

The problem is that the MM does not know about this dependencies and we have to introduce a lot of hack in the query system of Moose in order to be able to query those relations. I don't think the memory we save is worth the extra complexity it brings.

anneetien commented 4 years ago

I don’t understand why we should add a lot of hack in the query system. The idea is to say that if we have an attribute a of type A, there exist an association between a and A where a is the source and A the target. In that context, Moosequery should work. Where is the problem?

Anne

Le 14 mai 2020 à 18:38, CyrilFerlicot notifications@github.com a écrit :

The problem is that the MM does not know about this dependencies and we have to introduce a lot of hack in the query system of Moose in order to be able to query those relations. I don't think the memory we save is worth the extra complexity it brings.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/moosetechnology/Moose/issues/2092#issuecomment-628751572, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEH7WQ62SLQBEAP42NI23EDRRQNABANCNFSM4KOJA5EQ.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/moosetechnology/Moose/issues/2092#issuecomment-628751572", "url": "https://github.com/moosetechnology/Moose/issues/2092#issuecomment-628751572", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

jecisc commented 4 years ago

Since they are not reified as an association, the meta description does not know it is an association, there is no 'source' or 'target' and thus we need to search for them by hand, add them to the query results etc.. This makes the code of Moose Query more complexe and we cannot do everything we can do with other associations with type declarations since they are not reified.

jecisc commented 4 years ago

Another example of a problem caused by the fact that it is not reified is that it will not be possible to create navigation queries on them with the query model Clotilde is doing.

badetitou commented 4 years ago

I know we can have hacks etc. But it is a bad idea because it will certainly introduce bugs. So reify type declaration looks like a good idea for me too.

Sometimes it is interesting to not use association, but we have to be sure at 100% that we will not need them with Moose Query. IMO it is only for users models and not the one we proposed.

anneetien commented 4 years ago

I think it was the point of the issue to replace them by association ;-)

Anne

Le 20 mai 2020 à 13:49, CyrilFerlicot notifications@github.com a écrit :

Since they are not reified as an association, the meta description does not know it is an association, there is no 'source' or 'target' and thus we need to search for them by hand, add them to the query results etc.. This makes the code of Moose Query more complexe and we cannot do everything we can do with other associations with type declarations since they are not reified.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/moosetechnology/Moose/issues/2092#issuecomment-631425073, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEH7WQ5ARYZ432T5RED6FH3RSO7V3ANCNFSM4KOJA5EQ.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/moosetechnology/Moose/issues/2092#issuecomment-631425073", "url": "https://github.com/moosetechnology/Moose/issues/2092#issuecomment-631425073", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

NicolasAnquetil commented 4 years ago

May be we can do it without reifying the dependence and without creating a hack to?

We decide that dependence is a strong "property"that we want to be able to always compute. (seems a reasonable assumption to me)

We create "marker"of relations (in the sense of FamixMetamodelGenerator>>defineRelations) that create depedencies. e.g. (tTypedEntity property: #declaredType) isDependency

(note that all properties are not dependencies even if they have opposite entities, e.g. comment are sourceAnchor are not)

then we change queryOutgoingDependencies to collect all these relations. The from is the entity having the relation, and to is the entity in the property.

That would solve moosetechnology/Moose#2303 and moosetechnology/Moose#2304 also

NicolasAnquetil commented 4 years ago

Note: this could imply

At this moment in history, the 2nd option looks like the most promising, least disturbing to me

NicolasAnquetil commented 4 years ago

First analysis, possible steps :

anneetien commented 2 years ago

It seems that the relationQuery have solve this issue. What do you think @badetitou @NicolasAnquetil? Can we close this issue?

NicolasAnquetil commented 2 years ago

No, I think it is still on the table: by relation query you mean FamixQueries (I hate this name), the model behind the MiQueryBrowser?

If so, then the problem is solved for the MiQueryBrowser, but not for the MooseQueries, the API used by programmers. And we still need this API because we cannot do everything with the queryBrowser.

Any opinion on introducing a new dependency marker in the builder to mark relationships that introduce dependencies (see comment https://github.com/moosetechnology/Famix/issues/121#issuecomment-641462074)?