Home » Modeling » EMF » Internal structure of java method
| Internal structure of java method [message #538484] |
Mon, 07 June 2010 17:59  |
 Alexey 
Messages: 36
Registered: March 2010 |
Member |
|
|
Hi, all (and Ed in particular)
I am looking for some way, other than annotations, to specify internal structure of java method (EOperation). In the article http://www.ibm.com/developerworks/library/os-eclipse-emfmeta model/index.html (Generating concrete, reusable Java snippets), Ken McNeill shows one way. Which is creation of a metamodel (an extension of http://www.eclipse.org/emf/2002/Ecore) that adds something "EOperationX" that is actually an EClass (that extends EOperation). Then Ken uses EReference inside that EClass to model fragments of code. That approach seems to me a bit artificial, in other words, unnatural. EMF itself when it needs to generate some functional java code, using the trick which only works for ... EMF itself. I see it this way: EMF contains number of internally implemented services: persistence, notification, elements of validation, that capable of doing some very much predefined work. And then, using fixed (not extendable) metadata on eCore object, EMF generates delegation calls to those services. It works in a very narrow frame. May be enough for Eclipse internal needs and EMF specific object model, but that's it. I am interested in ability to generate code which is not so much restricted by EMF object and services model. In particularly, to express internal structure of (java) methods, at least in term of (unconditional) invocation from open set of "external" services: specify service element (by name) and set of actual invocation parameters. I believe that annotation construct is not a proper solution for such a problem.
So, is something in EMF that can help? Ken McNeill in the article given above had shown one way. Is there anything else more direct and natural for EMF?
|
|
|
| Re: Internal structure of java method [message #538560 is a reply to message #538484] |
Tue, 08 June 2010 00:14  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030203080708040101050205
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Alexey,
Comments below.
Alexey wrote:
> Hi, all (and Ed in particular)
>
> I am looking for some way, other than annotations, to specify internal
> structure of java method (EOperation). In the article
> http://www.ibm.com/developerworks/library/os-eclipse-emfmeta model/index.html
> (Generating concrete, reusable Java snippets), Ken McNeill shows one
> way. Which is creation of a metamodel (an extension of
> http://www.eclipse.org/emf/2002/Ecore) that adds something
> "EOperationX" that is actually an EClass (that extends EOperation).
> Then Ken uses EReference inside that EClass to model fragments of
> code. That approach seems to me a bit artificial, in other words,
> unnatural. EMF itself when it needs to generate some functional java
> code, using the trick which only works for ... EMF itself. I see it
> this way: EMF contains number of internally implemented services:
> persistence, notification, elements of validation, that capable of
> doing some very much predefined work. And then, using fixed (not
> extendable) metadata on eCore object, EMF generates delegation calls
> to those services. It works in a very narrow frame. May be enough for
> Eclipse internal needs and EMF specific object model, but that's it. I
> am interested in ability to generate code which is not so much
> restricted by EMF object and services model. In particularly, to
> express internal structure of (java) methods, at least in term of
> (unconditional) invocation from open set of "external" services:
> specify service element (by name) and set of actual invocation
> parameters. I believe that annotation construct is not a proper
> solution for such a problem.
Why?
> So, is something in EMF that can help? Ken McNeill in the article
> given above had shown one way. Is there anything else more direct and
> natural for EMF?
This release we added the ability to define behavior using pluggable
scripting language support:
http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Suppor t_for_Operation_Invocation_Delegates
It still uses annotations.
--------------030203080708040101050205
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Alexey,<br>
<br>
Comments below.<br>
<br>
<br>
Alexey wrote:
<blockquote cite="mid:hujc1f$hov$1@build.eclipse.org" type="cite">Hi,
all (and Ed in particular)
<br>
<br>
I am looking for some way, other than annotations, to specify internal
structure of java method (EOperation). In the article
<a class="moz-txt-link-freetext" href=" http://www.ibm.com/developerworks/library/os-eclipse-emfmeta model/index.html"> http://www.ibm.com/developerworks/library/os-eclipse-emfmeta model/index.html</a>
(Generating concrete, reusable Java snippets), Ken McNeill shows one
way. Which is creation of a metamodel (an extension of
<a class="moz-txt-link-freetext" href="http://www.eclipse.org/emf/2002/Ecore">http://www.eclipse.org/emf/2002/Ecore</a>) that adds something
"EOperationX" that is actually an EClass (that extends EOperation).
Then Ken uses EReference inside that EClass to model fragments of code.
That approach seems to me a bit artificial, in other words, unnatural.
EMF itself when it needs to generate some functional java code, using
the trick which only works for ... EMF itself. I see it this way: EMF
contains number of internally implemented services: persistence,
notification, elements of validation, that capable of doing some very
much predefined work. And then, using fixed (not extendable) metadata
on eCore object, EMF generates delegation calls to those services. It
works in a very narrow frame. May be enough for Eclipse internal needs
and EMF specific object model, but that's it. I am interested in
ability to generate code which is not so much restricted by EMF object
and services model. In particularly, to express internal structure of
(java) methods, at least in term of (unconditional) invocation from
open set of "external" services: specify service element (by name) and
set of actual invocation parameters. I believe that annotation
construct is not a proper solution for such a problem.
<br>
</blockquote>
Why?<br>
<blockquote cite="mid:hujc1f$hov$1@build.eclipse.org" type="cite">So,
is something in EMF that can help? Ken McNeill in the article given
above had shown one way. Is there anything else more direct and natural
for EMF? <br>
</blockquote>
This release we added the ability to define behavior using pluggable
scripting language support:<br>
<blockquote><a
href=" http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Suppor t_for_Operation_Invocation_Delegates"> http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Suppor t_for_Operation_Invocation_Delegates</a><br>
</blockquote>
It still uses annotations.<br>
<br>
</body>
</html>
--------------030203080708040101050205--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Internal structure of java method [message #538773 is a reply to message #538484] |
Tue, 08 June 2010 15:27 |
Alexey
Messages: 36
Registered: March 2010 |
Member |
|
|
Ed,
thanks for answering. The topic "Support for Operation Invocation Delegates" seems interesting. I will read it all carefully. When "Milestone 4" can be available? What means "this release"?
I think annotation mechanism is not appropriate to specify the internal structure of operatios, because annotations are obviously external objects, attached to operation. If you even try to express the simple sequence of invocations (delegations), even then you need to map in your mind externally described sequence into operation. It's just not a right way to do things, not structural, not along with MDA or OO culture. At least that is how I see it
I believe the better way - to add Delegation element as child to Operation. Allow to construct parameters of delegation from parameters of operation. As next step, allow to add DecisionMaking elements chile element to operation. And then, allow recursive CodeBlocks construct inside operation, consisting from other CodeBlock, DecisionMaking and Delegation elements...At least that is about how I see it. In some sence, it would mean extending EMF with some form of activities and appropriate diagrams, digesting next piece of UML.
Well, may be you have different and better vision how EMF should progress, but that (your better vision) seems not available for outsiders....
Thanks
Alexey
|
|
|
| Re: Internal structure of java method [message #538789 is a reply to message #538773] |
Tue, 08 June 2010 15:51 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Alexey,
Comments below.
Alexey wrote:
> Ed,
> thanks for answering. The topic "Support for Operation Invocation
> Delegates" seems interesting. I will read it all carefully. When
> "Milestone 4" can be available?
This is part of the Helios coordinated release.
> What means "this release"?
EMF 2.6 which releases with Eclipse 3.6 as part of Helios the last week
of June.
>
> I think annotation mechanism is not appropriate to specify the
> internal structure of operatios, because annotations are obviously
> external objects, attached to operation.
They're contained objects so I'm not sure what you're implying by the
word "external".
> If you even try to express the simple sequence of invocations
> (delegations), even then you need to map in your mind externally
> described sequence into operation. It's just not a right way to do
> things, not structural, not along with MDA or OO culture. At least
> that is how I see it
Even in Java, an operation body is effectively some text contained
within curly braces. In a textual representation of Ecore, e.g.,
Emfatic, it would appear the same way.
>
> I believe the better way - to add Delegation element as child to
> Operation.
Annotations are contained children.
> Allow to construct parameters of delegation from parameters of
> operation. As next step, allow to add DecisionMaking elements chile
> element to operation. And then, allow recursive CodeBlocks construct
> inside operation, consisting from other CodeBlock, DecisionMaking and
> Delegation elements...
So you're talking about an entire structurally modeled abstract syntax
tree for a statement and expression language. That's also possible, but
we're not in the "business" of defining yet another Turing complete
programming language. It's an interest possibility though.
> At least that is about how I see it. In some sence, it would mean
> extending EMF with some form of activities and appropriate diagrams,
> digesting next piece of UML.
As it stands, people acan and have plugged in support for OCL and
Javascript.
>
> Well, may be you have different and better vision how EMF should
> progress, but that (your better vision) seems not available for
> outsiders....
Eclipse modeling is like a layered and I see description of behavior as
something others should be able to add as an additional layer rather
than something that should be fundamentally dictated by a single
implementation in the EMF core itself.
>
> Thanks
>
> Alexey
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Internal structure of java method [message #538983 is a reply to message #538484] |
Wed, 09 June 2010 09:11 |
Eclipse User |
|
|
|
Originally posted by: formatzeh.gmx.de
Hi Alexey,
another solution is eJava [1]. With eJava you can specify your
operations bodies seperately in an own file. It really feels like normal
java except very few new keywords. You can import normal Java
dependencies and other model elements as well. Then a builder generates
the resulting code as annotation in the ecore file. The advantage is
that depending on the properties of the genmodel the right code will be
generated. For example you can use a term like '#YourMetaClass' as a
placeholder for the creation of a new instance of the class
YourMetaClass. If the use of a factory is defined in the genmodel it
will be translated to this factory. I can really recommend eJava.
best regards,
Gilbert
[1] http://www.emftext.org/index.php/EMFText_Concrete_Syntax_Zoo _eJava
|
|
|
Goto Forum:
Current Time: Fri Apr 19 20:35:44 GMT 2024
Powered by FUDForum. Page generated in 0.03155 seconds |
] 
Search
Help
Register
Login
Home
