| regarding Conclusion to "... Model Integrity in EMF with EMFT OCL" [message #43647] |
Mon, 07 August 2006 10:25  |
Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------090403000403020602030608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Conclusion states:
We used the EMF GenModel's dynamic template support to extend the
code generation system. A more complete implementation would use the
new (in EMF 2.2) adapter-based generator extensibility framework
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=75925#c8> with
statically compiled templates to transform OCL expressions into
Java^(TM) for maximal efficiency. For the subset of OCL for which
EMFT OCL provides evaluation support, transformation to Java^(TM)
would not be very difficult and could even surpass EMFT's evaluation
capabilities (e.g., by implementing @pre expressions in operation
postcondition constraints).
Please elaborate on the teasers in the above? (would, could, etc.)
OCL codegen seems like it should be / could be / (would be?)
incorporated in the default EMF codegen.
--------------090403000403020602030608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Arial">Conclusion states:<br>
</font>
<blockquote><font face="Arial">We used the EMF GenModel's dynamic
template support to extend the code generation
system. <font color="#000000">A more complete implementation</font>
would use the new (in EMF 2.2) adapter-based
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=75925#c8">generator
extensibility framework</a>
with statically compiled templates to transform
OCL expressions into Java™ for maximal efficiency. For the subset of
OCL for which
EMFT OCL provides evaluation support, transformation to Java™ would not
be very
difficult and could even surpass EMFT's evaluation capabilities (e.g.,
by
implementing @pre expressions in operation postcondition constraints).<br>
</font></blockquote>
<br>
<font face="Arial">Please elaborate on the teasers in the above?
(would, could, etc.)<br>
<br>
OCL codegen seems like it should be / could be / (would be?)
incorporated in the default EMF codegen.<br>
<br>
</font><br>
</body>
</html>
--------------090403000403020602030608--
|
|
|
| Re: regarding Conclusion to "... Model Integrity in EMF with EMFT OCL" [message #43830 is a reply to message #43647] |
Tue, 08 August 2006 09:26  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Dan,
There is no plan to incorporate OCL into any of EMF's code-generation
templates. These remarks in my conclusion were just intended to propose a
fun little exercise to anyone who has an interest in compilers, to
transform OCL to Java. This would make a good follow-up article, to
explore the OCL's abstract syntax (via EMFT OCL's AST model) together with
EMF's new codegen extensibility, which is not yet documented except in
examples (such as UML2 provides in its code generation support). It would
be great to see somebody contribute such an article ...
Cheers,
Christian
Dan Connelly wrote:
> Conclusion states:
>
> We used the EMF GenModel's dynamic template support to extend the
> code generation system. A more complete implementation would use the
> new (in EMF 2.2) adapter-based generator extensibility framework
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=75925#c8> with
> statically compiled templates to transform OCL expressions into
> Java^(TM) for maximal efficiency. For the subset of OCL for which
> EMFT OCL provides evaluation support, transformation to Java^(TM)
> would not be very difficult and could even surpass EMFT's evaluation
> capabilities (e.g., by implementing @pre expressions in operation
> postcondition constraints).
>
>
> Please elaborate on the teasers in the above? (would, could, etc.)
>
> OCL codegen seems like it should be / could be / (would be?)
> incorporated in the default EMF codegen.
|
|
|
| Re: regarding Conclusion to "... Model Integrity in EMF with EMFT OCL" [message #584683 is a reply to message #43647] |
Tue, 08 August 2006 09:26 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Dan,
There is no plan to incorporate OCL into any of EMF's code-generation
templates. These remarks in my conclusion were just intended to propose a
fun little exercise to anyone who has an interest in compilers, to
transform OCL to Java. This would make a good follow-up article, to
explore the OCL's abstract syntax (via EMFT OCL's AST model) together with
EMF's new codegen extensibility, which is not yet documented except in
examples (such as UML2 provides in its code generation support). It would
be great to see somebody contribute such an article ...
Cheers,
Christian
Dan Connelly wrote:
> Conclusion states:
>
> We used the EMF GenModel's dynamic template support to extend the
> code generation system. A more complete implementation would use the
> new (in EMF 2.2) adapter-based generator extensibility framework
> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=75925#c8> with
> statically compiled templates to transform OCL expressions into
> Java^(TM) for maximal efficiency. For the subset of OCL for which
> EMFT OCL provides evaluation support, transformation to Java^(TM)
> would not be very difficult and could even surpass EMFT's evaluation
> capabilities (e.g., by implementing @pre expressions in operation
> postcondition constraints).
>
>
> Please elaborate on the teasers in the above? (would, could, etc.)
>
> OCL codegen seems like it should be / could be / (would be?)
> incorporated in the default EMF codegen.
|
|
|
Powered by
FUDForum. Page generated in 0.03861 seconds
Home