Hi Alex,
I saw that you removed FAMIXFunction from FAMIX-Core. Is there a particular reason for this?
But, there is a larger issue here. FAMIX-Core is not meant to be programmed, but instead it should be generate-able from the MSE specification of FAMIX. So, basically a test should be to create an MSE from the descriptions from FAMIX-Core and then regenerate exactly the same classes back.
Like this, we can make sure that it remains portable and in sync (via Fame) with implementations in other languages.
To deal with the implementation details, there is a Famix- Implementation package.
Cheers, Doru
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
I have always encountered troubles understanding the maelstrom famix2/ famix3/fame. Shame on me, I probably did not spend enough time on reading paper and trying them out. I removed FAMIXFunction since Simon told me that the core was meant to not be manually reprogrammed. Since I have no idea how to describes FAMIXFunction in Fame, I am playing on the safe side.
Cheers, Alexandre
On 17 Mar 2009, at 23:46, Tudor Girba wrote:
Hi Alex,
I saw that you removed FAMIXFunction from FAMIX-Core. Is there a particular reason for this?
But, there is a larger issue here. FAMIX-Core is not meant to be programmed, but instead it should be generate-able from the MSE specification of FAMIX. So, basically a test should be to create an MSE from the descriptions from FAMIX-Core and then regenerate exactly the same classes back.
Like this, we can make sure that it remains portable and in sync (via Fame) with implementations in other languages.
To deal with the implementation details, there is a Famix- Implementation package.
Cheers, Doru
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 18 mars 09, at 09:28, Bergel, Alexandre wrote:
I have always encountered troubles understanding the maelstrom famix2/famix3/fame. Shame on me, I probably did not spend enough time on reading paper and trying them out. I removed FAMIXFunction since Simon told me that the core was meant to not be manually reprogrammed. Since I have no idea how to describes FAMIXFunction in Fame, I am playing on the safe side.
Actually having FAMIXFunction in the Core is not a problem, as long as it only contains metadescribed attributes and classes. As Doru says, the goal is to have a generative and auto-testing core through Fame export/generation. Then, for example, methods belonging to FAMIXFunction but not metadescribed should be class extensions defined in their own package.
However, I would like to keep the FAMIX-Core minimal as I believe it is quite complete.
Here is the current structure of Famix3 packages
Famix-Core: meta-described entities and attributes Famix-Implementation: mostly generic class extensions, like helper methods, which can not be meta-described Famix-Extensions: quite generic stuff, but does not belong to core, like metrics, the Visitor... Famix-Smalltalk: class extensions and classes specific to Smalltalk model (for example, FAMIXMethod is extended with a #categories attribute) Famix-Java: class extensions and classes specific to Java model Famix-File: an extension to describe a file structure etc.
My recommendation: do your stuff in your own package, dont think about the metadescriptions, you can integrate them later once your model has settled. It will be easier.
Cheers, Alexandre
On 17 Mar 2009, at 23:46, Tudor Girba wrote:
Hi Alex,
I saw that you removed FAMIXFunction from FAMIX-Core. Is there a particular reason for this?
But, there is a larger issue here. FAMIX-Core is not meant to be programmed, but instead it should be generate-able from the MSE specification of FAMIX. So, basically a test should be to create an MSE from the descriptions from FAMIX-Core and then regenerate exactly the same classes back.
Like this, we can make sure that it remains portable and in sync (via Fame) with implementations in other languages.
To deal with the implementation details, there is a Famix- Implementation package.
Cheers, Doru
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
My recommendation: do your stuff in your own package, dont think about the metadescriptions, you can integrate them later once your model has settled. It will be easier.
I prefer this, but I might need them of the browser... I will probably come back on this point soon.
Alexandre
Cheers, Alexandre
On 17 Mar 2009, at 23:46, Tudor Girba wrote:
Hi Alex,
I saw that you removed FAMIXFunction from FAMIX-Core. Is there a particular reason for this?
But, there is a larger issue here. FAMIX-Core is not meant to be programmed, but instead it should be generate-able from the MSE specification of FAMIX. So, basically a test should be to create an MSE from the descriptions from FAMIX-Core and then regenerate exactly the same classes back.
Like this, we can make sure that it remains portable and in sync (via Fame) with implementations in other languages.
To deal with the implementation details, there is a Famix- Implementation package.
Cheers, Doru
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
I did not want my previous mail to sound like scolding, I just wanted to start the discussion on what the expectations are :).
Simon summarized it quite nicely.
However, coming back to FAMIXFunction, I think that it should be in the core. The reason is that we sell FAMIX-Core as the core of a language independent meta-model. So, by default the basic concepts should be in, and FAMIXFunction is quite important for languages like Lisp or C/C++.
Cheers, Doru
On 18 Mar 2009, at 10:05, Alexandre Bergel wrote:
My recommendation: do your stuff in your own package, dont think about the metadescriptions, you can integrate them later once your model has settled. It will be easier.
I prefer this, but I might need them of the browser... I will probably come back on this point soon.
Alexandre
Cheers, Alexandre
On 17 Mar 2009, at 23:46, Tudor Girba wrote:
Hi Alex,
I saw that you removed FAMIXFunction from FAMIX-Core. Is there a particular reason for this?
But, there is a larger issue here. FAMIX-Core is not meant to be programmed, but instead it should be generate-able from the MSE specification of FAMIX. So, basically a test should be to create an MSE from the descriptions from FAMIX-Core and then regenerate exactly the same classes back.
Like this, we can make sure that it remains portable and in sync (via Fame) with implementations in other languages.
To deal with the implementation details, there is a Famix- Implementation package.
Cheers, Doru
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
I did not want my previous mail to sound like scolding, I just wanted to start the discussion on what the expectations are :).
I agree on this. No problem at all. I should have added a :-)
Simon summarized it quite nicely.
However, coming back to FAMIXFunction, I think that it should be in the core. The reason is that we sell FAMIX-Core as the core of a language independent meta-model. So, by default the basic concepts should be in, and FAMIXFunction is quite important for languages like Lisp or C/C++.
I agree on this. Simon, do we spent few minutes this afternoon on this?
Cheers, Alexandre
On 18 Mar 2009, at 10:05, Alexandre Bergel wrote:
My recommendation: do your stuff in your own package, dont think about the metadescriptions, you can integrate them later once your model has settled. It will be easier.
I prefer this, but I might need them of the browser... I will probably come back on this point soon.
Alexandre
Cheers, Alexandre
On 17 Mar 2009, at 23:46, Tudor Girba wrote:
Hi Alex,
I saw that you removed FAMIXFunction from FAMIX-Core. Is there a particular reason for this?
But, there is a larger issue here. FAMIX-Core is not meant to be programmed, but instead it should be generate-able from the MSE specification of FAMIX. So, basically a test should be to create an MSE from the descriptions from FAMIX-Core and then regenerate exactly the same classes back.
Like this, we can make sure that it remains portable and in sync (via Fame) with implementations in other languages.
To deal with the implementation details, there is a Famix- Implementation package.
Cheers, Doru
-- www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot be done."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Bergel, Alexandre -
Simon Denier -
Tudor Girba