[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [oaw-wg] Xpand middleend and backend

Hi Andre,

we should discuss Xpand related issues on the M2T developer list.
Please find my comments below.

As my example showed, the middleend and backend improve the code generation performance for larger models. Even higher performance improvement can be expected for larger models than I included in the example as the convertion of the frontend AST to the backend AST introduces some overhead that will be cut off when compiler is available.

Sounds good. I haven't yet found the time to have a look (Sorry). Maybe it would be interesting for others to read some comparing numbers?

Furthermore the backend provides a foundation for further performance
improvements and integration with other languages such as OCL.
Therefore I propose to include the following bundles/features with Xpand into the helios release:


       org.eclipse.xtend.backend
       org.eclipse.xtend.backend.uml2types
       org.eclipse.xtend.backend.xsdtypes
       org.eclipse.xtend.middleend.xtend
       org.eclipse.xtend.middleend.xpand

Which version number should be given?

We're currently at 0.8.0. The bundles should have their own feature, as well.


Some bugs are still to be fixed. These relate to the convertion of the frontend typesystems for UML2 and XSD to their respective backend typesystems. Currently a converter in the middleend converts the types from frontend to backend. To go ahead with this approach, I would have to add getters for the stereotypes in StereotypeType and MultipleStereotypeType.

Making those types inspectable shouldn't be a problem.

Arno proposed a better solution that results in less dependencies in the
backend, avoiding to load all the typesystems, when they are not needed. His solution was to add a method "asBackendType" to every frontend type. Ideally every frontend type would implement an interface introducing the method "asBackendType". Frontend types would be better encapsulated then (meaning no additional getters). I could take care for implementing this approach. Would you be fine with the latter approach?

I think the current solution is nicer, since it does not create a strict dependency between frontend and backend.
Having an indirection (middleend), which is responsible for providing a backendtype seems to work well in both situations.


Later when the backend has been widely adopted, we could add the mentioned getter and slim done the middleend to a minimum.
But even than I'ld prefer to stick with the middleend abstraction, so it will be possible to integrate other languages with the backend without changing them (at least as long as they are introspectable).


As I understood, bugfixes can still be done during the next milestone. So I propose to include the bundles mentioned above into the Helios release.

Would it be ok to do the build integration after Tuesday's M5?
It is only a couple of days and Dennis (our Release Engineer) won't have any time to spend by then.


If we do the integration right after M5, there would be enough time to face and fix any build issues.

Cheers,
Sven