search

Minres / CoreDSL

Xtext project to parse CoreDSL files
Apache License 2.0
16 stars 3 forks source link

Feature/manual emf model #60

Closed eyck closed 2 years ago

eyck commented 2 years ago

Moves to a manually managed EMF model. This allows to add properties and enum values not in the grammar (see StorageClassSpecifier). @AtomCrafty Please check if this works with gradle and your nevironment

jopperm commented 2 years ago

+1 for going this route, but manually fiddling with these XML files looks terrible 😂 Are there any tools in Eclipse to modify them?

eyck commented 2 years ago

No one sait it would be easy B-)

There is no need to deal with ECore files directly. You may the Ecore editor (the fastest for quick changes) coming with the DSL flavor of Eclipse or you may use the EcoreTools available via the MarketPlace. This might then look like this:

grafik

AtomCrafty commented 2 years ago

How does this change affect the future workflow when modifying the grammar? Will all manual changes be discarded when the mwe2 workflow is executed again? Does "manual" mean the automatic generation of classes from the grammar is not available anymore?

eyck commented 2 years ago

Basically yes, 'manual' means the class definitions have to be maintained by hand. Therefore I did not put it on develop yet rather put it on a PR for discussion. If there are larger grammar changes (new or different rules) we should stick with the automatic approach. Unfortunately the the ability to change the generated classes has been removed from the XText framework,

Using this PR a grammar change will regenerate the infrastructure but not the ecore model. So if attributes or rules change you need to put this explicitly into the ecore model so that the classes are generated accordingly.

AtomCrafty commented 2 years ago

In that case I believe this isn't the best move right now. The language is still fairly immature and I expect it to change quite a bit as development progresses.

The issue we're trying to solve here can easily be circumvented by introducing a new StorageClass enum for internal use instead of extending the existing StorageClassSpecifier enum.

eyck commented 2 years ago

But how do you intend to tie it to a declaration as this is a generated class?

But ok, we just drop the PR.

AtomCrafty commented 2 years ago

The same way we tie any other analysis results to the AST nodes - with a map. The CoreDslAnalyzer.analyze method returns an AnalysisContext instance that contains all analysis results.