Community
Participate
Working Groups
Currently embedding Xbase in your language involves a couple of tasks to do. In addition to the integration of the grammar you need to tell 1) what the expected type of each expresson is 2) what's on the scope for an expression (i.e. local variables and the context type) 3) you need to write a transformation from you DSL concepts to the JvmModel in order to contribute types to the scope. 4) you need to write a generator Java code, often semantically identical to what has already been cerated in the JvmModel inferrer. We can improve on that 1) improving the API to create a JVMmodel out of a given DSL model. E.g. by means of the new builder syntax and a corresponding builder library. 2) Associate each expression with an element from the derived JVMmodel. Most of the time an expression lives in the context of derived JvmElement. If we have that association we can provide a very good default scoping and typing for these scenarios. That is in XbaseScopeProvide we should ask for the associated JvmElement if that exists create a scope beaded on that element. For a JvmOperation we would for instance put the parameters on the scope, use its declaring type as the context type, etc. We can also use the return type of a JvmOperation as the expected type in the type provider. 3) create a code generator which turns the JvmModel elements and the associated expressions into Java code. The existing hooks would still exist if one needs special treatment but for the majority of the cases this should work very well.
With such a change the domain model language can be defined by using the grammar as is and *only* provide the following code (a JvmInferrer using a builder syntax): class DomainmodelJvmModelInferrer extends AbstractModelInferrer { @Inject extension JvmTypesBuilder def dispatch infer(Entity e, IAcceptor<JvmDeclaredType> acceptor) { acceptor.accept( e.toClazz( e.name ) [ if (e.superType != null) superTypes += e.superType.cloneWithProxies for ( f : e.features ) { switch f { Property : { members += f.toField(f.name, f.type) members += f.toGetter(f.name, f.type) members += f.toSetter(f.name, f.type) } Operation : { members += f.toMethod(f.name, f.type) [ for (p : f.params) { parameters.add(p.toParameter(p.name, p.parameterType)) } ] } } } ] ) } } The code might change a bit as we work on this ticket, but it should illustrate the idea and the improvement.
That would be awesome - looking forward to updating the tutorial ;-)
the domain model example is now based on a new API which reuses the inferred JvmModel. Also PureXbase has been migrated. The generic Code regenerator as well as the builder API need to be further enhanced to support more of the JvmModel elements. Next step would be to make Xtend use the new approach.
Xtend2 now uses the proposed approach. Still open: Resolve name collisions of JvmElements created from create extensions.
Fixed duplicate names for create extensions.
closing this one. Please open dedicated bugzillas per concrete issue.
Closing all bugs that were set to RESOLVED before Neon.0
