Re-using operations in multiple EGL files [message #981550] |
Mon, 12 November 2012 09:07  |
Eclipse User |
|
|
|
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 #984020 is a reply to message #983972] |
Wed, 14 November 2012 05:37   |
Eclipse User |
|
|
|
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 #987237 is a reply to message #987234] |
Sat, 24 November 2012 17:06  |
Eclipse User |
|
|
|
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] by Moderator
|
|
|
Powered by
FUDForum. Page generated in 0.53476 seconds