Hi Cyrille,
The MSE Import Wizard is a good step forward, but it has a problem: The entity types are hardcoded. This is a big problem because we should be able to load any entity.
It would be better if that list would be gathered from the types from MooseModel meta.
ImportingContext should not be hardcoded either, but it should be computed from the same repository by traversing the properties.
For example, in FAMIXMethod>>parentType says that FAMIXClass is required for FAMIXMethod. In the same time, FAMIXMethod is not required for a FAMIXClass because the property FAMIXClass>>methods isDerived. Basically in this way, we should be able to create the graph dynamically and thus we can use the mechanisms for any meta-model.
What do you think?
In the meantime I restored the previous implementation as a temporary solution, because now we have PrimitiveType that should also be loadable.
Cheers, Doru
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
On Dec 3, 2009, at 10:46 PM, Tudor Girba wrote:
Hi Cyrille,
The MSE Import Wizard is a good step forward, but it has a problem: The entity types are hardcoded. This is a big problem because we should be able to load any entity.
It would be better if that list would be gathered from the types from MooseModel meta.
ImportingContext should not be hardcoded either, but it should be computed from the same repository by traversing the properties.
For example, in FAMIXMethod>>parentType says that FAMIXClass is required for FAMIXMethod. In the same time, FAMIXMethod is not required for a FAMIXClass because the property FAMIXClass>>methods isDerived. Basically in this way, we should be able to create the graph dynamically and thus we can use the mechanisms for any meta-model.
What do you think?
yes the design of ImportContext predates the one of FAME and indeed we should be able to have any metamodel and their dependency Now it may happen that we will found some hidden (manually expressed in the importingcontext and importer) dependency that are not expressed in the metamodel: famix comment, literal.
In the meantime I restored the previous implementation as a temporary solution, because now we have PrimitiveType that should also be loadable.
Cheers, Doru
-- www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 3 déc. 2009, at 18:57, Stéphane Ducasse wrote:
On Dec 3, 2009, at 10:46 PM, Tudor Girba wrote:
Hi Cyrille,
The MSE Import Wizard is a good step forward, but it has a problem: The entity types are hardcoded. This is a big problem because we should be able to load any entity.
It would be better if that list would be gathered from the types from MooseModel meta.
ImportingContext should not be hardcoded either, but it should be computed from the same repository by traversing the properties.
For example, in FAMIXMethod>>parentType says that FAMIXClass is required for FAMIXMethod. In the same time, FAMIXMethod is not required for a FAMIXClass because the property FAMIXClass>>methods isDerived. Basically in this way, we should be able to create the graph dynamically and thus we can use the mechanisms for any meta- model.
What do you think?
yes the design of ImportContext predates the one of FAME and indeed we should be able to have any metamodel and their dependency Now it may happen that we will found some hidden (manually expressed in the importingcontext and importer) dependency that are not expressed in the metamodel: famix comment, literal.
A related issue is to encode the importing context in the mse. So that we know what is not in the mse. See comment #2 in the issue
-- Simon
yes the design of ImportContext predates the one of FAME and indeed we should be able to have any metamodel and their dependency Now it may happen that we will found some hidden (manually expressed in the importingcontext and importer) dependency that are not expressed in the metamodel: famix comment, literal.
A related issue is to encode the importing context in the mse. So that we know what is not in the mse. See comment #2 in the issue
Yes we got something a bit like that (more the metamodel) when we developed CDIF exhcngae format. YOu would send the mmodel and the model. Now for the context why not.
Stef
Hi,
yes the design of ImportContext predates the one of FAME and indeed we should be able to have any metamodel and their dependency Now it may happen that we will found some hidden (manually expressed in the importingcontext and importer) dependency that are not expressed in the metamodel: famix comment, literal.
A related issue is to encode the importing context in the mse. So that we know what is not in the mse. See comment #2 in the issue
Yes we got something a bit like that (more the metamodel) when we developed CDIF exhcngae format. YOu would send the mmodel and the model. Now for the context why not.
I do not understand. What kind of details are we talking about that cannot be inferred from the meta-model?
Cheers, Doru
-- www.tudorgirba.com
"Speaking louder won't make the point worthier."
Hi,
yes the design of ImportContext predates the one of FAME and indeed we should be able to have any metamodel and their dependency Now it may happen that we will found some hidden (manually expressed in the importingcontext and importer) dependency that are not expressed in the metamodel: famix comment, literal.
A related issue is to encode the importing context in the mse. So that we know what is not in the mse. See comment #2 in the issue
Yes we got something a bit like that (more the metamodel) when we developed CDIF exhcngae format. YOu would send the mmodel and the model. Now for the context why not.
I do not understand. What kind of details are we talking about that cannot be inferred from the meta-model?
extraction of literals, comments, for example
Stef
Hi
yes the design of ImportContext predates the one of FAME and indeed we should be able to have any metamodel and their dependency Now it may happen that we will found some hidden (manually expressed in the importingcontext and importer) dependency that are not expressed in the metamodel: famix comment, literal.
A related issue is to encode the importing context in the mse. So that we know what is not in the mse. See comment #2 in the issue
Yes we got something a bit like that (more the metamodel) when we developed CDIF exhcngae format. YOu would send the mmodel and the model. Now for the context why not.
I do not understand. What kind of details are we talking about that cannot be inferred from the meta-model?
extraction of literals, comments, for example
What is with them? What can we not know about them?
FAMIXComment has a container pointing to FAMIXEntity. In this case, we will probably need to add all entities as prerequisites.
Doru
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing should have the right to be different."
On Dec 3, 2009, at 11:47 PM, Tudor Girba wrote:
Hi
yes the design of ImportContext predates the one of FAME and indeed we should be able to have any metamodel and their dependency Now it may happen that we will found some hidden (manually expressed in the importingcontext and importer) dependency that are not expressed in the metamodel: famix comment, literal.
A related issue is to encode the importing context in the mse. So that we know what is not in the mse. See comment #2 in the issue
Yes we got something a bit like that (more the metamodel) when we developed CDIF exhcngae format. YOu would send the mmodel and the model. Now for the context why not.
I do not understand. What kind of details are we talking about that cannot be inferred from the meta-model?
extraction of literals, comments, for example
What is with them? What can we not know about them?
I do not know I was wondering if FAMIX really cover all the entity that are extracted. At some points this was not the case
FAMIXComment has a container pointing to FAMIXEntity. In this case, we will probably need to add all entities as prerequisites.
You have also FAMIXLiteral?
Doru
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing should have the right to be different."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Stef,
> yes > the design of ImportContext predates the one of FAME and > indeed we should be able to have any metamodel and their > dependency > Now it may happen that we will found some hidden (manually > expressed in the importingcontext and importer) dependency > that are not expressed in the metamodel: famix comment, literal.
A related issue is to encode the importing context in the mse. So that we know what is not in the mse. See comment #2 in the issue
Yes we got something a bit like that (more the metamodel) when we developed CDIF exhcngae format. YOu would send the mmodel and the model. Now for the context why not.
I do not understand. What kind of details are we talking about that cannot be inferred from the meta-model?
extraction of literals, comments, for example
What is with them? What can we not know about them?
I do not know I was wondering if FAMIX really cover all the entity that are extracted. At some points this was not the case
FAMIXComment has a container pointing to FAMIXEntity. In this case, we will probably need to add all entities as prerequisites.
You have also FAMIXLiteral?
No, but we are talking about two different things :). I was saying that if I have a meta-model then the importing context dependencies should be derived from it, and I think we can do a reasonable job with this approach.
Of course, if we do not have the meta-model implemented, the importing context is not very useful anyway.
Doru
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
FAMIXComment has a container pointing to FAMIXEntity. In this case, we will probably need to add all entities as prerequisites.
You have also FAMIXLiteral?
No, but we are talking about two different things :).
No :)
I was saying that if I have a meta-model then the importing context dependencies should be derived from it, and I think we can do a reasonable job with this approach
Yes this is a good idea. This is what I said. Then I was wondering from the importer point of view if we could use this importingContext filled up based on the metamodel.
Of course, if we do not have the meta-model implemented, the importing context is not very useful anyway.
This is more subtle: I'm not sure ythat FAMIXLiteral (if it exist) is connected to the FAMIX30. But the importer has checks for them (at least from memory of the VW implementation) Stef
Doru
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Simon Denier -
Stéphane Ducasse -
Tudor Girba