There was major overhaul in the way how messaging is implemented in ELENA so in this tutorial I will once again cover this topic.
Unlike strong typed languages the process of invoking the method is called sending a message because the actual method resolving happens at run-time and is implemented by scanning through the target’s VMT. In ELENA it could be even more complex because the actual message can be calculated at run-time as well. It could be redirected to another object with the help of redirect method as well. So message sending is more powerful operation but it comes with a cost. In general it costs more than the conventional method calling. Using redirect handler adds another overhead. So it is not wonder that ELENA is slower than static binding languages. A lot of efforts were made in the new version to reduce this overhaul.
The major change was to allow several parameters to be passed with the message. Though it sounds simple in reality it required major changes in the language implementation, especially parameter dispatch routine (currently it still can be done only for single parameter). The order of parameters in the stack had to be reversed; redirect algorithm was modified and so on. Another change was an introduction of open argument list
Now, let’s look at messaging in details
As in the most of dynamic object-oriented languages the main way to interact with objects in ELENA is sending a message. Unlike others the message name is structured and consists of a verb, a signature and a parameter counter. The verb defines a message action, for example read or write some data. There are only limited set of possible verbs (e.g. eval[uate], add, set, get, run, seek and so on). In general the signature is user defined and describes the message parameters. It can be used to define some custom action as well (e.g. writeLine, which in fact is eval&writeLine(1)). If the signature is not provided the message is considered to be generic and can be qualified (for example by dispatching).
If the object wants to handle the message it has to contain the method with the same name. If no method mapping was found the flow is considered to be broken and the control goes to the next alternative flow (exception handler) or the program is stopped.
The simple code to send a message looks like this:
Note: "write" is a generic message; a literal constant is a parameter.
Several messages can be send in one statement, the parameter itself may be result of object interactions:
We could use operators to have the shorter code:
Note: In most cases "<<" is a synonym to "write" and "+" to "add".
Several parameters can be passed in the message as well:
Ampersand is used to indicate that the signature has several arguments (subjects). The actual message name is eval&foreach&do(2).
The generic message can have several parameters as well:
To be continued...