Code model consolidation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Code model consolidation

Henrik Sperre Johansen
I was under the impression the plan was to standardize on Ring as the meta model to use; to replace ChangeRecord / MCDefinition.
However, after Ring as added to the image in 2011, no further work as been done to actually replace the ChangeRecord / MCDefinition use though, and I recently ran into Yet Another, new(ish)ly added, code model; the codeImport extraction/rewrite introduces a new CodeDeclaration + subclasses.

Maybe it's time to take a step back, put this on the roadmap, and actually prioritize the hard task of basing our tools on Ring?
Or at least refuse accepting new contributions which further muddy the waters...

Cheers,
Henry
Reply | Threaded
Open this post in threaded view
|

Re: Code model consolidation

stepharo
Hi Henrik
> I was under the impression the plan was to standardize on Ring as the meta model to use; to replace ChangeRecord / MCDefinition.
We do not know if ring is for replacing changeRecord. I'm not sure that
we can.
Ring is to have a representation of a program not the file
representation of program (now may be we could extend it).
We will extend it/improve to have a full compilation unit. Now Ring is
about programs not file representation.
We removed recently Pseudo* metamodel and FilePackage and the old tools
to browse cs and st file.
What we would like to do is to be able to remove RB program model to use
Ring instead. But somebody has to help because
we are full.
> However, after Ring as added to the image in 2011, no further work as been done to actually replace the ChangeRecord / MCDefinition use though, and I recently ran into Yet Another, new(ish)ly added, code model; the codeImport extraction/rewrite introduces a new CodeDeclaration + subclasses.
There are different models: Codeimporter is a model of chunk format.
(you know the ugly stuff where the parser is coded by hand....). Now we
created a simple declaration entity hierarchy to avoid to have isKindOf
and other uglies everywhere.
>
> Maybe it's time to take a step back, put this on the roadmap, and actually prioritize the hard task of basing our tools on Ring?
> Or at least refuse accepting new contributions which further muddy the waters...
Code Importer is a project with a clear goal: parsing/saving chunk
formatter stuff.
Its visitor may create ring objects that are displayed in an external
browser (when you press code browse)
or if you want to have them in chunk format for now. Or create
MCMethodDefinition.

Ideally we would like to remove chunk format and codeImporter would go
away.
We would love