Home » Modeling » EMF » EOperation invocation
| EOperation invocation [message #378643] |
Tue, 24 June 2003 23:29  |
Eclipse User |
|
|
|
Originally posted by: organmorgan123.yahoo.com
As far as I can tell there is no way to invoke an EOperation. Why not?
Thanks,
Tim
|
|
|
| Re: EOperation invocation [message #378647 is a reply to message #378643] |
Wed, 25 June 2003 13:37  |
 David Steinberg
Messages: 489
Registered: July 2009 |
Senior Member |
|
|
Tim Klinger wrote:
> As far as I can tell there is no way to invoke an EOperation. Why not?
Hi Tim,
What would it do? :)
Seriously, EOperation really only exists for completeness; it's not nearly
as central a piece of Ecore as EStructuralFeature. Really, since we don't
model behaviour, an EOperation only models the *interface* of an operation.
When you generate code for a model, stubs are generated for EOperations,
which you can use to supply your own implementation. You could imagine, I
suppose, that we could have a reflective method -- call it eInvoke() -- that
is an analog to eGet(), calling out to the appropriate generated (and
hand-filled-in) method. But what would happen in the dynamic case?
EObjectImpl provides implementations for dynanic structural features, which
are accessed by eGet(), eSet(), etc., but what kind of implementation could
it provide for an operation?
The uniformity of dynamic and generated models is one of the important
features of EMF. Since we could only ever support generated models with an
eInvoke(), you have to ask if it's worth the bother. Java already provides
a handy way to reflectively invoke methods, and there's nothing to stop you
from using that with generated models. You can get the java.lang.Class for
the generated interface from the EClass by calling getInstanceClass().
Cheers,
Dave
|
|
|
| Re: EOperation invocation [message #378651 is a reply to message #378647] |
Wed, 25 June 2003 15:28 |
| Eclipse User |
|
|
|
Originally posted by: organmorgan123.yahoo.com
Dave Steinberg wrote:
> Tim Klinger wrote:
> > As far as I can tell there is no way to invoke an EOperation. Why not?
> Hi Tim,
> What would it do? :)
It would act as an analog to Method.invoke().
> Seriously, EOperation really only exists for completeness; it\'s not nearly
> as central a piece of Ecore as EStructuralFeature. Really, since we don\'t
> model behaviour, an EOperation only models the *interface* of an operation.
The \"Method\" class models the interface of a class operation and the
invoke method takes an instance of the class at runtime and actually calls
the operation on that instance. No behavior is being modeled there either.
> When you generate code for a model, stubs are generated for EOperations,
> which you can use to supply your own implementation. You could imagine, I
> suppose, that we could have a reflective method -- call it eInvoke() -- that
> is an analog to eGet(), calling out to the appropriate generated (and
> hand-filled-in) method. But what would happen in the dynamic case?
> EObjectImpl provides implementations for dynanic structural features, which
> are accessed by eGet(), eSet(), etc., but what kind of implementation could
> it provide for an operation?
I am not suggesting supporting dynamic addition of operation
implementations. I am just suggesting adding a method called \"invoke\" to
EOperation (not EObject) which could be implemented by finding the
corresponding Method owned by the java instance class and calling invoke
on it.
> The uniformity of dynamic and generated models is one of the important
> features of EMF. Since we could only ever support generated models with an
> eInvoke(), you have to ask if it\'s worth the bother. Java already provides
> a handy way to reflectively invoke methods, and there\'s nothing to stop you
> from using that with generated models. You can get the java.lang.Class for
> the generated interface from the EClass by calling getInstanceClass().
It\'s worth the bother because being able to dynamically change the model
is not the only useful thing you can do with it. For instance, you can
write an interpreter that evaluates expressions over EMF models. To
evaluate an expression you can use regular java reflection but it\'s
annoying to have to translate between the two worlds. Right now, to
invoke an operation reflectively, I have to get the java instance class of
an EClass metaobject, find the appropriate Method on that class and call
invoke on the object. I think EOperation should do this for me.
> Cheers,
> Dave
By the way, JMI (Java Metadata Interface) offers this capability in its
reflection package.
--Tim
|
|
|
| Re: EOperation invocation [message #378670 is a reply to message #378651] |
Thu, 26 June 2003 12:25 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Tim,
Although we've have considered providing support for reflective EOperation
invocation---it's a pretty obvious missing thing---there's never been a strong
case for how it would be used. In fact, you're the first actual client to bring up
the issue, so it's certainly not mainstream function that has broad application.
Your example of an interpreter is an interesting one though. But even for that,
it's clear that determining the java.lang.reflect.Method given an EOperation is
something that can be done external to the Ecore model. So I could imagine Ecore
providing a transient volatile feature, EOperation.instanceMethod, that returns
the EJavaMethod, i.e., java.lang.reflect.Method, but that would just be a nice
convenience for a very small number of clients rather than a necessity for any
client. Supporting invoke on EOperation seems not very useful if that's just
going to call invoke on the Method; it seems better to provide access to the
Method, which then supports invoke.
As Dave suggested, we need to take dynamic Ecore into account and with the current
design there is no way for EOperations to be implemented unless they are code
generated. Note the analog to EStructuralFeature is (sort of)
java.lang.reflect.Field and that although Field has a "get" method,
EStructuralFeature does not have a "get" method; instead EObject has an eGet
method which supports access even when there is no generated code. Similarly,
although java.lang.Class has a newInstance method, EClassifier doesn't have a
create method; instead EFactory has a create method which supports creation even
where there is no Class. That's why Dave is suggesting that EOperation shouldn't
have an invoke method but instead EObject should have an eInvoke method. Then one
could imagine that a reflective invocation on an EObject could be mapped, even in
the dynamic case when there is no Method, to some type of behavior. I.e., one
might "register" a static method that can be called to implement the EOperation.
I'll discuss this issue further with the rest of the group, but since this looks
more like a convenience than a necessity, it's not likely that we'd take action
immediately. (But you're welcome to try to strengthen the argument for this type
of support. ;-)
Tim Klinger wrote:
> Dave Steinberg wrote:
>
> > Tim Klinger wrote:
> > > As far as I can tell there is no way to invoke an EOperation. Why not?
>
> > Hi Tim,
>
> > What would it do? :)
>
> It would act as an analog to Method.invoke().
>
> > Seriously, EOperation really only exists for completeness; it\'s not nearly
> > as central a piece of Ecore as EStructuralFeature. Really, since we don\'t
> > model behaviour, an EOperation only models the *interface* of an operation.
>
> The \"Method\" class models the interface of a class operation and the
> invoke method takes an instance of the class at runtime and actually calls
> the operation on that instance. No behavior is being modeled there either.
>
> > When you generate code for a model, stubs are generated for EOperations,
> > which you can use to supply your own implementation. You could imagine, I
> > suppose, that we could have a reflective method -- call it eInvoke() -- that
> > is an analog to eGet(), calling out to the appropriate generated (and
> > hand-filled-in) method. But what would happen in the dynamic case?
> > EObjectImpl provides implementations for dynanic structural features, which
> > are accessed by eGet(), eSet(), etc., but what kind of implementation could
> > it provide for an operation?
>
> I am not suggesting supporting dynamic addition of operation
> implementations. I am just suggesting adding a method called \"invoke\" to
> EOperation (not EObject) which could be implemented by finding the
> corresponding Method owned by the java instance class and calling invoke
> on it.
>
> > The uniformity of dynamic and generated models is one of the important
> > features of EMF. Since we could only ever support generated models with an
> > eInvoke(), you have to ask if it\'s worth the bother. Java already provides
> > a handy way to reflectively invoke methods, and there\'s nothing to stop you
> > from using that with generated models. You can get the java.lang.Class for
> > the generated interface from the EClass by calling getInstanceClass().
>
> It\'s worth the bother because being able to dynamically change the model
> is not the only useful thing you can do with it. For instance, you can
> write an interpreter that evaluates expressions over EMF models. To
> evaluate an expression you can use regular java reflection but it\'s
> annoying to have to translate between the two worlds. Right now, to
> invoke an operation reflectively, I have to get the java instance class of
> an EClass metaobject, find the appropriate Method on that class and call
> invoke on the object. I think EOperation should do this for me.
>
> > Cheers,
> > Dave
>
> By the way, JMI (Java Metadata Interface) offers this capability in its
> reflection package.
>
> --Tim
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: EOperation invocation [message #1723671 is a reply to message #1723662] |
Wed, 17 February 2016 07:38 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
So old that it's not in my history. Much has changed in the meantime. In
particular a genmodel option allows eInvoke() to be available for
modeled operations (i.e. not for EObject).
OCL lacks an ElementLiteralExp with new
OperationLiteralExp/PropertyLiteralExp subclasses. Only
EumerationLiteralExp/TypeExp exists.
If they existed, research is needed into the type safety with respect to
a possible oclGet(), oclInvoke(). [no oclSet() of course.]
A concrete syntax for the literals is a bit challenging given the
pragmatic decision to have no distinctive syntax for type literals as in
oclIsKindOf(String).
Regards
Ed Willink
On 17/02/2016 07:15, Yves BERNARD wrote:
> Guys,
>
> May I awaken this old discussion?
>
> I think that it is worth reconsidering this point.
>
> Indeed with the development of executable semantics for UML models
> (cf. fUML, Precise Semantics for UML Composite Structure and the
> upcoming Precise Semantics for UML State Machines) application based
> on model execution should increase in the near future. So, providing
> the ability to invoke behaviors (directly or through behavioral
> features) definitively make sense to me.
>
> For instance: in OCL expressions that will be evaluated at runtime
> (e.g. guards), I would like to be able to refer to features defined in
> my model. Today, I can do this with structural feature, but not with
> behavioral ones.
>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 06:28:39 GMT 2024
Powered by FUDForum. Page generated in 0.01769 seconds |
] 
Search
Help
Register
Login
Home
