Hi everybody
I'm trying to use iPlasma to parse Java source files, export the model as MSE, then import them in SqMoose using Fame.
I ran into a couple of problems when doing this, specificall the MSE format built with iPlasma is not well parsed by Fame.
Here is a sample generated by iPlasma:
Beginning of MSE file:
(Moose.Model (entity
A) According to the MSE spec, the file cant begin directly with a name like that, should be ((Moose.Model (entity (....)) Besides, I dont see the point of this header, it works fine without it.
(FAMIX.Namespace (id: 6) (name 'java::lang') )
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
(FAMIX.Class (id: 3) (name 'Object') (belongsTo (idref: 6)) (isAbstract false) (isInterface false)
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
My suggestion is that each Famix metamodel should explicitely declare its version in its Fame package name, either Famix2 or Famix3, like that: FAMIXClass class>>annotation <MSEClass: #Class super: 'FAMIX3.Type'> <package: #FAMIX3> ^self
Does it sound ok?
-- Simon
Hi Simon,
iPlasma exports for Moose/Meta/FAMIX 2.1, and the file is incompatible with Moose/Fame/FAMIX 3.0 because of two reasons: 1. because the MSE syntax changed slightly 2. because FAMIX changed
The syntax of MSE is stable now. When we will get a stable version of FAMIX, I will work to create another exporter from iPlasma.
Cheers, Doru
On Feb 3, 2009, at 5:59 PM, Simon Denier wrote:
Hi everybody
I'm trying to use iPlasma to parse Java source files, export the model as MSE, then import them in SqMoose using Fame.
I ran into a couple of problems when doing this, specificall the MSE format built with iPlasma is not well parsed by Fame.
Here is a sample generated by iPlasma:
Beginning of MSE file:
(Moose.Model (entity
A) According to the MSE spec, the file cant begin directly with a name like that, should be ((Moose.Model (entity (....)) Besides, I dont see the point of this header, it works fine without it.
(FAMIX.Namespace (id: 6) (name 'java::lang') )
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
(FAMIX.Class (id: 3) (name 'Object') (belongsTo (idref: 6)) (isAbstract false) (isInterface false)
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
My suggestion is that each Famix metamodel should explicitely declare its version in its Fame package name, either Famix2 or Famix3, like that: FAMIXClass class>>annotation <MSEClass: #Class super: 'FAMIX3.Type'> <package: #FAMIX3> ^self
Does it sound ok?
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
On 3 févr. 09, at 18:05, Tudor Girba wrote:
Hi Simon,
iPlasma exports for Moose/Meta/FAMIX 2.1, and the file is incompatible with Moose/Fame/FAMIX 3.0 because of two reasons:
- because the MSE syntax changed slightly
- because FAMIX changed
The syntax of MSE is stable now. When we will get a stable version of FAMIX, I will work to create another exporter from iPlasma.
I'm cool with that, but do you have a date in mind?
Still I think it will be good to use the FAMIX2/FAMIX3 convention suggested below to distinguish between both model in MSE, simply to avoid name mismatch. It will be a minor fix and for older importer, a batch replacement of FAMIXx by FAMIX is not very difficult.
PS: my personal opinion is that the Famix3 implementation in SqMoose is now usable, although some tests are still red (more related to Moose than to Famix) and there should still be some bugs in some place. (disclaimer :) currently the Smalltalk importer does not infer previous/next attributes in Famix Association)
So it's not an official announcement, but we will begin to use it for our own work.
Cheers, Doru
On Feb 3, 2009, at 5:59 PM, Simon Denier wrote:
Hi everybody
I'm trying to use iPlasma to parse Java source files, export the model as MSE, then import them in SqMoose using Fame.
I ran into a couple of problems when doing this, specificall the MSE format built with iPlasma is not well parsed by Fame.
Here is a sample generated by iPlasma:
Beginning of MSE file:
(Moose.Model (entity
A) According to the MSE spec, the file cant begin directly with a name like that, should be ((Moose.Model (entity (....)) Besides, I dont see the point of this header, it works fine without it.
(FAMIX.Namespace (id: 6) (name 'java::lang') )
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
(FAMIX.Class (id: 3) (name 'Object') (belongsTo (idref: 6)) (isAbstract false) (isInterface false)
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
My suggestion is that each Famix metamodel should explicitely declare its version in its Fame package name, either Famix2 or Famix3, like that: FAMIXClass class>>annotation <MSEClass: #Class super: 'FAMIX3.Type'> <package: #FAMIX3> ^self
Does it sound ok?
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
-- Simon
Hi,
I disagree for the version name to be in the name of the package. The version should be marked outside of the actual data.
I would suggest to create a header with this kind of meta data.
Regarding iPlasma, I believe it would take slightly long until the exporter gets in the release of iPlasma. This is because iPlasma is not open source.
But, in the meantime, I would actually suggest to create a script to translate the existing FAMIX 2.1 Meta/MSE into the new FAMIX 3.0 Fame/ MSE using Regexp or something like that.
Cheers, Doru
On Feb 3, 2009, at 6:33 PM, Simon Denier wrote:
On 3 févr. 09, at 18:05, Tudor Girba wrote:
Hi Simon,
iPlasma exports for Moose/Meta/FAMIX 2.1, and the file is incompatible with Moose/Fame/FAMIX 3.0 because of two reasons:
- because the MSE syntax changed slightly
- because FAMIX changed
The syntax of MSE is stable now. When we will get a stable version of FAMIX, I will work to create another exporter from iPlasma.
I'm cool with that, but do you have a date in mind?
Still I think it will be good to use the FAMIX2/FAMIX3 convention suggested below to distinguish between both model in MSE, simply to avoid name mismatch. It will be a minor fix and for older importer, a batch replacement of FAMIXx by FAMIX is not very difficult.
PS: my personal opinion is that the Famix3 implementation in SqMoose is now usable, although some tests are still red (more related to Moose than to Famix) and there should still be some bugs in some place. (disclaimer :) currently the Smalltalk importer does not infer previous/next attributes in Famix Association)
So it's not an official announcement, but we will begin to use it for our own work.
Cheers, Doru
On Feb 3, 2009, at 5:59 PM, Simon Denier wrote:
Hi everybody
I'm trying to use iPlasma to parse Java source files, export the model as MSE, then import them in SqMoose using Fame.
I ran into a couple of problems when doing this, specificall the MSE format built with iPlasma is not well parsed by Fame.
Here is a sample generated by iPlasma:
Beginning of MSE file:
(Moose.Model (entity
A) According to the MSE spec, the file cant begin directly with a name like that, should be ((Moose.Model (entity (....)) Besides, I dont see the point of this header, it works fine without it.
(FAMIX.Namespace (id: 6) (name 'java::lang') )
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
(FAMIX.Class (id: 3) (name 'Object') (belongsTo (idref: 6)) (isAbstract false) (isInterface false)
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
My suggestion is that each Famix metamodel should explicitely declare its version in its Fame package name, either Famix2 or Famix3, like that: FAMIXClass class>>annotation <MSEClass: #Class super: 'FAMIX3.Type'> <package: #FAMIX3> ^self
Does it sound ok?
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
-- Simon
-- www.tudorgirba.com
"When people care, great things can happen."
On Feb 3, 2009, at 8:32 PM, Tudor Girba wrote:
Hi,
I disagree for the version name to be in the name of the package. The version should be marked outside of the actual data.
I would suggest to create a header with this kind of meta data.
Regarding iPlasma, I believe it would take slightly long until the exporter gets in the release of iPlasma. This is because iPlasma is not open source.
Doru just a question. What would happen if you are not working on reengineering in the future? Will be they willing to still let us use iplasma to export FAMIX?
But, in the meantime, I would actually suggest to create a script to translate the existing FAMIX 2.1 Meta/MSE into the new FAMIX 3.0 Fame/MSE using Regexp or something like that.
Cheers, Doru
On Feb 3, 2009, at 6:33 PM, Simon Denier wrote:
On 3 févr. 09, at 18:05, Tudor Girba wrote:
Hi Simon,
iPlasma exports for Moose/Meta/FAMIX 2.1, and the file is incompatible with Moose/Fame/FAMIX 3.0 because of two reasons:
- because the MSE syntax changed slightly
- because FAMIX changed
The syntax of MSE is stable now. When we will get a stable version of FAMIX, I will work to create another exporter from iPlasma.
I'm cool with that, but do you have a date in mind?
Still I think it will be good to use the FAMIX2/FAMIX3 convention suggested below to distinguish between both model in MSE, simply to avoid name mismatch. It will be a minor fix and for older importer, a batch replacement of FAMIXx by FAMIX is not very difficult.
PS: my personal opinion is that the Famix3 implementation in SqMoose is now usable, although some tests are still red (more related to Moose than to Famix) and there should still be some bugs in some place. (disclaimer :) currently the Smalltalk importer does not infer previous/next attributes in Famix Association)
So it's not an official announcement, but we will begin to use it for our own work.
Cheers, Doru
On Feb 3, 2009, at 5:59 PM, Simon Denier wrote:
Hi everybody
I'm trying to use iPlasma to parse Java source files, export the model as MSE, then import them in SqMoose using Fame.
I ran into a couple of problems when doing this, specificall the MSE format built with iPlasma is not well parsed by Fame.
Here is a sample generated by iPlasma:
Beginning of MSE file:
(Moose.Model (entity
A) According to the MSE spec, the file cant begin directly with a name like that, should be ((Moose.Model (entity (....)) Besides, I dont see the point of this header, it works fine without it.
(FAMIX.Namespace (id: 6) (name 'java::lang') )
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
(FAMIX.Class (id: 3) (name 'Object') (belongsTo (idref: 6)) (isAbstract false) (isInterface false)
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
My suggestion is that each Famix metamodel should explicitely declare its version in its Fame package name, either Famix2 or Famix3, like that: FAMIXClass class>>annotation <MSEClass: #Class super: 'FAMIX3.Type'> <package: #FAMIX3> ^self
Does it sound ok?
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
-- Simon
-- www.tudorgirba.com
"When people care, great things can happen."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
iPlasma binary has an unclear license. It only says that it is available for people that were part of LOOSE, but as they made it freely downloadable I believe the intention is to have it usable by anyone. I will try to check.
Cheers, Doru
On Feb 3, 2009, at 9:54 PM, Stéphane Ducasse wrote:
On Feb 3, 2009, at 8:32 PM, Tudor Girba wrote:
Hi,
I disagree for the version name to be in the name of the package. The version should be marked outside of the actual data.
I would suggest to create a header with this kind of meta data.
Regarding iPlasma, I believe it would take slightly long until the exporter gets in the release of iPlasma. This is because iPlasma is not open source.
Doru just a question. What would happen if you are not working on reengineering in the future? Will be they willing to still let us use iplasma to export FAMIX?
But, in the meantime, I would actually suggest to create a script to translate the existing FAMIX 2.1 Meta/MSE into the new FAMIX 3.0 Fame/MSE using Regexp or something like that.
Cheers, Doru
On Feb 3, 2009, at 6:33 PM, Simon Denier wrote:
On 3 févr. 09, at 18:05, Tudor Girba wrote:
Hi Simon,
iPlasma exports for Moose/Meta/FAMIX 2.1, and the file is incompatible with Moose/Fame/FAMIX 3.0 because of two reasons:
- because the MSE syntax changed slightly
- because FAMIX changed
The syntax of MSE is stable now. When we will get a stable version of FAMIX, I will work to create another exporter from iPlasma.
I'm cool with that, but do you have a date in mind?
Still I think it will be good to use the FAMIX2/FAMIX3 convention suggested below to distinguish between both model in MSE, simply to avoid name mismatch. It will be a minor fix and for older importer, a batch replacement of FAMIXx by FAMIX is not very difficult.
PS: my personal opinion is that the Famix3 implementation in SqMoose is now usable, although some tests are still red (more related to Moose than to Famix) and there should still be some bugs in some place. (disclaimer :) currently the Smalltalk importer does not infer previous/next attributes in Famix Association)
So it's not an official announcement, but we will begin to use it for our own work.
Cheers, Doru
On Feb 3, 2009, at 5:59 PM, Simon Denier wrote:
Hi everybody
I'm trying to use iPlasma to parse Java source files, export the model as MSE, then import them in SqMoose using Fame.
I ran into a couple of problems when doing this, specificall the MSE format built with iPlasma is not well parsed by Fame.
Here is a sample generated by iPlasma:
Beginning of MSE file:
(Moose.Model (entity
A) According to the MSE spec, the file cant begin directly with a name like that, should be ((Moose.Model (entity (....)) Besides, I dont see the point of this header, it works fine without it.
(FAMIX.Namespace (id: 6) (name 'java::lang') )
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
(FAMIX.Class (id: 3) (name 'Object') (belongsTo (idref: 6)) (isAbstract false) (isInterface false)
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
My suggestion is that each Famix metamodel should explicitely declare its version in its Fame package name, either Famix2 or Famix3, like that: FAMIXClass class>>annotation <MSEClass: #Class super: 'FAMIX3.Type'> <package: #FAMIX3> ^self
Does it sound ok?
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
-- Simon
-- www.tudorgirba.com
"When people care, great things can happen."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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."
Ok so this implies that we should speed up on FAMIX30 implementation to debug it?
On Feb 3, 2009, at 6:05 PM, Tudor Girba wrote:
Hi Simon,
iPlasma exports for Moose/Meta/FAMIX 2.1, and the file is incompatible with Moose/Fame/FAMIX 3.0 because of two reasons:
- because the MSE syntax changed slightly
- because FAMIX changed
The syntax of MSE is stable now. When we will get a stable version of FAMIX, I will work to create another exporter from iPlasma.
Cheers, Doru
On Feb 3, 2009, at 5:59 PM, Simon Denier wrote:
Hi everybody
I'm trying to use iPlasma to parse Java source files, export the model as MSE, then import them in SqMoose using Fame.
I ran into a couple of problems when doing this, specificall the MSE format built with iPlasma is not well parsed by Fame.
Here is a sample generated by iPlasma:
Beginning of MSE file:
(Moose.Model (entity
A) According to the MSE spec, the file cant begin directly with a name like that, should be ((Moose.Model (entity (....)) Besides, I dont see the point of this header, it works fine without it.
(FAMIX.Namespace (id: 6) (name 'java::lang') )
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
(FAMIX.Class (id: 3) (name 'Object') (belongsTo (idref: 6)) (isAbstract false) (isInterface false)
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
My suggestion is that each Famix metamodel should explicitely declare its version in its Fame package name, either Famix2 or Famix3, like that: FAMIXClass class>>annotation <MSEClass: #Class super: 'FAMIX3.Type'> <package: #FAMIX3> ^self
Does it sound ok?
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
thanks for the feedback. This is great that you tried that.
Stef On Feb 3, 2009, at 5:59 PM, Simon Denier wrote:
Hi everybody
I'm trying to use iPlasma to parse Java source files, export the model as MSE, then import them in SqMoose using Fame.
I ran into a couple of problems when doing this, specificall the MSE format built with iPlasma is not well parsed by Fame.
Here is a sample generated by iPlasma:
Beginning of MSE file:
(Moose.Model (entity
A) According to the MSE spec, the file cant begin directly with a name like that, should be ((Moose.Model (entity (....)) Besides, I dont see the point of this header, it works fine without it.
(FAMIX.Namespace (id: 6) (name 'java::lang') )
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
(FAMIX.Class (id: 3) (name 'Object') (belongsTo (idref: 6)) (isAbstract false) (isInterface false)
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
My suggestion is that each Famix metamodel should explicitely declare its version in its Fame package name, either Famix2 or Famix3, like that: FAMIXClass class>>annotation <MSEClass: #Class super: 'FAMIX3.Type'> <package: #FAMIX3> ^self
Does it sound ok?
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Simon,
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
Property name and method name do not necessarily have to match. Currently setter names are created by appending a colon to the getter name. Should be straight forward to extend Fame with a custom strategy.
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
Where did you get that specification? I should update it and replace all IDREF with REF (we made that change to save bytes in the often huge MSE documents).
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
Fame does not support versioning (yet). It is up to clients to adopt their own versioning convention. Personally I do as you suggest.
cheers, AA
On 4 févr. 09, at 01:12, Adrian Kuhn wrote:
Hi Simon,
B) Fame infers accessor 'smalltalk-style', ie it will call #name: to set the name of the Namespace entity in the example above. It works in Famix3 but not in Famix2, where the setter is declared as #setName: . It's alright with the inference rule of Meta (as I far as I remember) but not with the new one. We should add those accessors in Famix2 for seamless access.
Property name and method name do not necessarily have to match. Currently setter names are created by appending a colon to the getter name. Should be straight forward to extend Fame with a custom strategy.
C) Fame does not recognize the idref: syntax, only the ref: syntax. The MSE spec is inconsistent about that: the grammar only defines the ref: syntax as Fame does, but the doc talks about both an IDREF command and a 'REF command for metamodels only'.
Where did you get that specification? I should update it and replace all IDREF with REF (we made that change to save bytes in the often huge MSE documents).
It's here: http://smallwiki.unibe.ch/fame/msespecification/
D) Finally, the biggest hurdle is that we dont know directly with which version of Famix the file was created. For example, the FAMIX package in SqMoose matches Famix3, and Famix2 is defined in a FAMIX2 package. This leads to a mismatch when trying to load the above file which was generated with Famix2 (unless batch editing all FAMIX -> FAMIX2)
Fame does not support versioning (yet). It is up to clients to adopt their own versioning convention. Personally I do as you suggest.
cheers, AA _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
Fixed.
On 04.02.2009, at 13:12, Simon Denier wrote:
Where did you get that specification? I should update it and replace all IDREF with REF (we made that change to save bytes in the often huge MSE documents).
tx
On Feb 24, 2009, at 1:36 PM, Adrian Kuhn wrote:
Fixed.
On 04.02.2009, at 13:12, Simon Denier wrote:
Where did you get that specification? I should update it and replace all IDREF with REF (we made that change to save bytes in the often huge MSE documents).
-
Adrian Kuhn -
Simon Denier -
Simon Denier
-
stephane ducasse -
Stéphane Ducasse -
Tudor Girba