Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Epsilon » Re-using operations in multiple EGL files
Re-using operations in multiple EGL files [message #981550] Mon, 12 November 2012 09:07 Go to next message
Joost van Pinxten is currently offline Joost van Pinxten
Messages: 50
Registered: November 2012
Member
When I declare that a model element has a getGlobalName operation and a getLocalName operation, I would like, for consistency, to have just one copy of these operations defined.

But as I call these operations in different egl templates, it seems that I need to copy them, or the operations won't be defined.

Is there any way to make operations defined in one template accessible to other templates?
Re: Re-using operations in multiple EGL files [message #981555 is a reply to message #981550] Mon, 12 November 2012 09:10 Go to previous messageGo to next message
Dimitris Kolovos is currently offline Dimitris Kolovos
Messages: 804
Registered: July 2009
Senior Member
Hi Joost,

You can define your operations in a .eol file and then import it from your .egl templates.

Cheers,
Dimitris
Re: Re-using operations in multiple EGL files [message #981568 is a reply to message #981555] Mon, 12 November 2012 09:21 Go to previous messageGo to next message
Joost van Pinxten is currently offline Joost van Pinxten
Messages: 50
Registered: November 2012
Member
Hi Dimitris,

Cheers, hadn't thought of that. I will try this out!

Joost
Re: Re-using operations in multiple EGL files [message #982641 is a reply to message #981550] Tue, 13 November 2012 04:44 Go to previous messageGo to next message
Joost van Pinxten is currently offline Joost van Pinxten
Messages: 50
Registered: November 2012
Member
I actually did read about this in the Epsilon Book, but forgot about it as the related passage uses the emphasis (italized) in two distinct ways here. The first is to indicate a concept, while the second use (for import) is to state, as I understand now, the concrete syntax?

I would suggest to change the style of the "import" part, as I think this is confusing. If at all possible, or logical, the structure of imports (what is allowed where?) Wouldn't it be convenient to state this somewhere in a general chapter, e.g. in a dependency diagram?
Re: Re-using operations in multiple EGL files [message #983972 is a reply to message #982641] Wed, 14 November 2012 04:45 Go to previous messageGo to next message
Antonio Garcia-Dominguez is currently offline Antonio Garcia-Dominguez
Messages: 304
Registered: January 2010
Senior Member
Do you remember the location of the passage in the book, so we can fix the problem?

There's this paragraph in the book (last paragraph in p. 119) saying that any EOL statement (including the 'import' statement) can be used within the dynamic part of an EGL script:

"Any EOL statement can be contained in the dynamic sections of an EGL template. For example, the EGL template depicted in Listing 7.3 generates text from a model that conforms to a metamodel that describes an object-oriented system."

Perhaps we should mention imports in this paragraph as well?
Re: Re-using operations in multiple EGL files [message #984020 is a reply to message #983972] Wed, 14 November 2012 05:37 Go to previous messageGo to next message
Joost van Pinxten is currently offline Joost van Pinxten
Messages: 50
Registered: November 2012
Member
The section I mentioned is section 3.1: Module Organization on page 23. I think section 3.1 is a good place to also state the actual syntax. I would consider making a concrete example. The "Rule and Block Overriding" sections already state what kind of module can also be imported (addtional to EOL modules). Creating a kind of dependency graph between module types can also help here. E.g. how EML, EVL, ETL, and EOL modules can reference one another.

"Modules can also import other modules using import statements, and access their operations." <- this is good information, but it's a good idea to show the readers how to do this. The concrete syntax is missing here.

It might be a good idea to break listing 3.1 into two different listings, such that "operation Integer add2()" is imported into the other listing and then both are called. Or to create another example here, so that the complexity of the example does not become too high.

Also, as far as I can see, there are two ways to import: using relative and absolute paths. It might be convenient to mention this here too.

I haven't tried this, but are conditional imports allowed (like in PHP's 'require' and 'include')? Or should the import always occur at the top level, before any other type of statement?
Re: Re-using operations in multiple EGL files [message #987234 is a reply to message #984020] Sat, 24 November 2012 14:59 Go to previous messageGo to next message
Antonio Garcia-Dominguez is currently offline Antonio Garcia-Dominguez
Messages: 304
Registered: January 2010
Senior Member
Sorry for the delay: it's been a busy week Sad.

I have added a new example at the beginning of Section 3.1 showing how imports work. Could you have a look at it? The example also mentions that we can use absolute paths, relative paths or even platform:/ URIs.

As for conditional imports, I'm afraid those aren't supported. Import statements must be at the top level, since the E*L engines will statically parse the scripts looking for them.
Re: Re-using operations in multiple EGL files [message #987237 is a reply to message #987234] Sat, 24 November 2012 17:06 Go to previous message
Joost van Pinxten is currently offline Joost van Pinxten
Messages: 50
Registered: November 2012
Member
Ok, that looks fine to me. However, now that we are on the subject, mentioning that the body is the part up until the first (non-imported) operation should also be noted here:

consider this test.eol:
// prints 1
1.println();

// this operation defines the end of the (executable) body of this eol file
operation Integer test () {
	"test".println();
}

// Does not print anything
1.test();


This is not a documented feature and led me to report bug 393988.

My suggestion is to change this section into something like the attached image, as my latex-fu is not up to par to create something along that spirit. Basically, I'm trying to include the fact that a source file consists of three pieces: first piece consists of import statements, second piece consists of a sequence of "normal" statements that are executed, and the third piece contains operation definitions, in which normal statements aren't executed.

However, I recognize that this piece of information (about module contents and organization) may not be well structured anymore. How about splitting it up:

\section{Module Organization}

In this section the syntax of EOL is presented in a top-down manner. As displayed in Figure \ref{fig:EOL.Module}, EOL programs are organized in \emph{modules}. Modules can import other modules using \emph{import} statements and access their operations, as shown in Listing~\ref{lst:ExampleImports}.

Each module may define a 
\begin{enumerate}
  \item number of \emph{import} statements
  \item block of EOL statements to execute
  \item and a number of \emph{operations}.
\end{enumerate}
The body is a block of statements that are evaluated when the module is executed. Each operation defines the kind of objects on which it is applicable (\emph{context}), a \emph{name}, a set of \emph{parameters} and optionally a \emph{return type}. The body ends when the first operation definition is encountered and thus statements outside an operation will be silently ignored after the first operation definition.


I know that this is all very basic stuff, but I think it's important for developers new to Epsilon to be able to fall back on the information, as it is the actual reference for all things related to Epsilon. Thank you for your time!

[Updated on: Sat, 24 November 2012 17:06]

Report message to a moderator

Previous Topic:[EVL] Quick Fix is disabled
Next Topic:Epsilon profiling tools missing?
Goto Forum:
  


Current Time: Fri Aug 01 09:54:29 EDT 2014

Powered by FUDForum. Page generated in 0.01695 seconds