Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Additional constructors the EMF way?
Additional constructors the EMF way? [message #415279] Mon, 10 December 2007 08:40 Go to next message
Volker Stolz is currently offline Volker StolzFriend
Messages: 63
Registered: July 2009
Member
I am looking for a way how to generate additional constructors in an EMF
(ECore derived from UML) model, not modifying the existing code generation
templates as has been discussed in the archives.

I tried adding a new Operation using the class name as the Operation Name
and the arguments I want to pass, but the returned type/EType is a problem:
if I leave the EType empty, EMF will generate "public void Foo(...)", if I
set the type to the Class name, I'll get "public Foo Foo(...)" (and of
course I can't leave the name empty so that the returned type shows up in
the right place in the output :-).

Is there any official way to achieve this instead of editing the generated
file (or simply writing helper classes)?
Re: Additional constructors the EMF way? [message #415281 is a reply to message #415279] Mon, 10 December 2007 10:39 Go to previous messageGo to next message
Alexandros Karypidis is currently offline Alexandros KarypidisFriend
Messages: 32
Registered: July 2009
Member
Volker Stolz wrote:
> I am looking for a way how to generate additional constructors in an EMF
> (ECore derived from UML) model, not modifying the existing code
> generation templates as has been discussed in the archives.
>
> I tried adding a new Operation using the class name as the Operation
> Name and the arguments I want to pass, but the returned type/EType is a
> problem:
> if I leave the EType empty, EMF will generate "public void Foo(...)", if
> I set the type to the Class name, I'll get "public Foo Foo(...)" (and of
> course I can't leave the name empty so that the returned type shows up
> in the right place in the output :-).
>
> Is there any official way to achieve this instead of editing the
> generated file (or simply writing helper classes)?

Hi Volker,

I don't know of a way to add constructor definitions in the Ecore model.
However, even if you could specify constructor declarations by add
"operations" with the same name as the class, what would you expect EMF
to generate? The generated implementation could probably be one that
initializes some structural features of your class with the constructor
arguments, but anything beyond that would have to be written by hand.
Furthermore, EMF would probably need a no-argument constructor for itself.

My 5 cents is that you should continue adding the constructors by
coding. After all EMF-generated code is officially meant to be edited. :-)

Alexandros
Re: Additional constructors the EMF way? [message #415296 is a reply to message #415281] Mon, 10 December 2007 21:45 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33216
Registered: July 2009
Senior Member
Alexandros,

I agree. Since the factory invokes the default constructor and you need
such things for copying and deserializing instances, at best additional
constructors are a convenience and you will need to write the code by
hand. I would expect that there would be hand written convenience
methods in the factory and that they could be written without additional
constructors imply by using existing accessor methods to modify the
newly created instance.


Alexandros Karypidis wrote:
> Volker Stolz wrote:
>> I am looking for a way how to generate additional constructors in an
>> EMF (ECore derived from UML) model, not modifying the existing code
>> generation templates as has been discussed in the archives.
>>
>> I tried adding a new Operation using the class name as the Operation
>> Name and the arguments I want to pass, but the returned type/EType is
>> a problem:
>> if I leave the EType empty, EMF will generate "public void Foo(...)",
>> if I set the type to the Class name, I'll get "public Foo Foo(...)"
>> (and of course I can't leave the name empty so that the returned
>> type shows up in the right place in the output :-).
>>
>> Is there any official way to achieve this instead of editing the
>> generated file (or simply writing helper classes)?
>
> Hi Volker,
>
> I don't know of a way to add constructor definitions in the Ecore
> model. However, even if you could specify constructor declarations by
> add "operations" with the same name as the class, what would you
> expect EMF to generate? The generated implementation could probably be
> one that initializes some structural features of your class with the
> constructor arguments, but anything beyond that would have to be
> written by hand. Furthermore, EMF would probably need a no-argument
> constructor for itself.
>
> My 5 cents is that you should continue adding the constructors by
> coding. After all EMF-generated code is officially meant to be edited.
> :-)
>
> Alexandros


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Additional constructors the EMF way? [message #415342 is a reply to message #415296] Thu, 13 December 2007 06:39 Go to previous messageGo to next message
Volker Stolz is currently offline Volker StolzFriend
Messages: 63
Registered: July 2009
Member
Alexandros, Ed, thanks for your answers; having to it by hand will not be
a problem. However, from a "symmetry point-of-view", a constructor
is not that different from an operation that I already can specify
(and which I'll also have to fill out), so in an MDD approach, I
still see some value in being able to specify additional constructors
as well. A generated stub could e.g. simply call the basic constructor
and ignore any arguments that might be specified for the constructor,
couldn't it?

Volker
--
United Nations University - http://www.iist.unu.edu/~vs/
International Institute for Software Technology Macau SAR, China
Re: Additional constructors the EMF way? [message #415343 is a reply to message #415342] Thu, 13 December 2007 08:04 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33216
Registered: July 2009
Senior Member
Volker,

Comments below.


Volker Stolz wrote:
> Alexandros, Ed, thanks for your answers; having to it by hand will not be
> a problem. However, from a "symmetry point-of-view", a constructor
> is not that different from an operation that I already can specify
> (and which I'll also have to fill out), so in an MDD approach, I
> still see some value in being able to specify additional constructors
> as well.
An EOperation corresponds to a method that will be visible in the
interface as something you'd expect to be able to invoke on an instance,
but a constructor isn't like that at all. It's more like a static
method that's only available on a class, not on an interface, and can
only be invoked in a very special way.
> A generated stub could e.g. simply call the basic constructor
> and ignore any arguments that might be specified for the constructor,
> couldn't it?
>
Ecore doesn't just try to just duplicate everything in Java. So there
is no notion of public, protected, and private, nor static or
constants. Constructors at best should be a convenience and generally a
factory is the way clients should create instances...
> Volker
>


Ed Merks
Professional Support: https://www.macromodeling.com/
User-defined code generation [message #415345 is a reply to message #415343] Thu, 13 December 2007 08:32 Go to previous messageGo to next message
Alexandros Karypidis is currently offline Alexandros KarypidisFriend
Messages: 32
Registered: July 2009
Member
Having said that, how come there is no way to feed the EMF code
generator with user-written .javajet files? EMF does not and should not
try to duplicate everything in Java, but it would be pretty neat if I
could add my own JET transformations to an EMF project and have EMF
generated code from it.

I like this idea a lot, because it would allow people to implement
extensions (such as this one). Once I feel comfortable with the EMF
codebase, I will try to implement this and hopefully contribute a patch.

The way I think this could work is to add an extension point that will
allow PDE projects that contain a model to specify .javajet resources
that should be included in code generation phase.

Ed Merks wrote:

> [...]
> Ecore doesn't just try to just duplicate everything in Java. So there
> is no notion of public, protected, and private, nor static or
> constants. Constructors at best should be a convenience and generally a
> factory is the way clients should create instances...
Re: User-defined code generation [message #415351 is a reply to message #415345] Thu, 13 December 2007 14:23 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33216
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030703070408020102090500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Alexandros,

You can use dynamic templates to modify EMF's base templates:

2.29 What are Dynamic Templates?
< http://wiki.eclipse.org/index.php/EMF-FAQ#What_are_Dynamic_T emplates.3F>

There are all kinds of insertion points in Class.javajet that would
allow you to write just the snips of the template you want to modify.
And org.eclipse.emf.examples.generator.validator shows how you can
extend the generator with additional templates.


Alexandros Karypidis wrote:
> Having said that, how come there is no way to feed the EMF code
> generator with user-written .javajet files? EMF does not and should
> not try to duplicate everything in Java, but it would be pretty neat
> if I could add my own JET transformations to an EMF project and have
> EMF generated code from it.
>
> I like this idea a lot, because it would allow people to implement
> extensions (such as this one). Once I feel comfortable with the EMF
> codebase, I will try to implement this and hopefully contribute a patch.
>
> The way I think this could work is to add an extension point that will
> allow PDE projects that contain a model to specify .javajet resources
> that should be included in code generation phase.
>
> Ed Merks wrote:
>
>> [...]
>> Ecore doesn't just try to just duplicate everything in Java. So
>> there is no notion of public, protected, and private, nor static or
>> constants. Constructors at best should be a convenience and
>> generally a factory is the way clients should create instances...


--------------030703070408020102090500
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">
</head>
<body bgcolor="#ffffff" text="#000000">
Alexandros,<br>
<br>
You can use dynamic templates to modify EMF's base templates:<br>
<blockquote><a
href=" http://wiki.eclipse.org/index.php/EMF-FAQ#What_are_Dynamic_T emplates.3F"><span
class="tocnumber">2.29</span> <span class="toctext">What are Dynamic
Templates?</span></a><br>
</blockquote>
There are all kinds of insertion points in Class.javajet that would
allow you to write just the snips of the template you want to modify.&nbsp;
And org.eclipse.emf.examples.generator.validator shows how you can
extend the generator with additional templates.<br>
<br>
<br>
Alexandros Karypidis wrote:
<blockquote cite="mid:fjqqmg$gan$1@build.eclipse.org" type="cite">Having
said that, how come there is no way to feed the EMF code generator with
user-written .javajet files? EMF does not and should not try to
duplicate everything in Java, but it would be pretty neat if I could
add my own JET transformations to an EMF project and have EMF generated
code from it.
<br>
<br>
I like this idea a lot, because it would allow people to implement
extensions (such as this one). Once I feel comfortable with the EMF
codebase, I will try to implement this and hopefully contribute a
patch.
<br>
<br>
The way I think this could work is to add an extension point that will
allow PDE projects that contain a model to specify .javajet resources
that should be included in code generation phase.
<br>
<br>
Ed Merks wrote:
<br>
<br>
<blockquote type="cite">[...]
<br>
Ecore doesn't just try to just duplicate everything in Java.&nbsp; So there
is no notion of public, protected, and private, nor static or
constants.&nbsp; Constructors at best should be a convenience and generally
a factory is the way clients should create instances...
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>

--------------030703070408020102090500--


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[Announce] Joint Eclipse/OMG Symposia
Next Topic:available Resource implementations
Goto Forum:
  


Current Time: Thu Sep 19 09:34:07 GMT 2024

Powered by FUDForum. Page generated in 0.03117 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top