Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 356977

Summary:	[Xbase] Make embedding Xbase easier
Product:	[Modeling] TMF	Reporter:	Sven Efftinge <sven.efftinge>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	jan, sebastian.zarnekow
Version:	2.1.0	Flags:	sven.efftinge: indigo+
Target Milestone:	SR2
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:

Description Sven Efftinge

2011-09-07 13:34:44 EDT

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.

Comment 1 Sven Efftinge

2011-09-07 13:38:53 EDT

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.

Comment 2 Sebastian Zarnekow

2011-09-07 13:41:54 EDT

That would be awesome - looking forward to updating the tutorial ;-)

Comment 3 Sven Efftinge

2011-09-19 04:57:39 EDT

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.

Comment 4 Jan Koehnlein

2011-10-10 06:13:44 EDT

Xtend2 now uses the proposed approach. 

Still open: Resolve name collisions of JvmElements created from create extensions.

Comment 5 Jan Koehnlein

2011-10-10 08:48:03 EDT

Fixed duplicate names for create extensions.

Comment 6 Sven Efftinge

2011-10-13 10:01:48 EDT

closing this one. Please open dedicated bugzillas per concrete issue.

Comment 7 Karsten Thoms

2017-09-19 17:19:48 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 8 Karsten Thoms

2017-09-19 17:31:20 EDT

Closing all bugs that were set to RESOLVED before Neon.0