On 17.04.2024 21:04, Bob Bridges wrote:
This whole post was fascinating me, partly because I'm still a novice at
ooRexx, still wrapping my head around certain concepts (messaging being one
example). I may as well say, though, that when I finally broke down and got
myself a copy, I then took not one hour but two or three days off to read the
documentation before I started writing the program I had in mind. There was so
much more to it than I expected, having believed that it would be simply
TSO-REXX with object support.
Messaging...As I said, I'm still wrapping my head around that. I'm used to creating
classes and then invoking their methods; to use the term "message" in this
connection causes my brain to pause temporarily. So far the only thing I've worked out
is that messaging ~is~ invoking a class' method, that is, it's just another way of saying
the same thing. But the way you describe it, I suspect I'm missing something.
My take is that people tend to believe that there is more to the messaging
paradigm than there is. :)
Think of a message expression to be something comparable to a call instruction or a function
invocation, it will cause code to be executed like the others.
The nice thing about the message paradigm "receiver~message" is that the receiver is responsible to
find a method (a routine defined in its structure, class, type) and invoke it. The receiver will
take the name of the received message and starts to look for a method by the same name in its own
class (the structure used to create the receiver). If the method is not found by the receiver, the
receiver will look up the immediate superclass for the method and if not found, that superclass'
superclass up the class hierarchy to the root class. The first method found in this lookup process
will be the one the receiver will run, supplying any arguments the message carries and returning any
result to the caller. This effectively realizes inheritance.
The programmer only needs to know about the functionality (methods and attributes/fields) documented
for the class/structure/type that was used to create the receiver. Because of inheritance all
functionality (methods and attributes/fields) on the shortest path to the root of the class
hierarchy is available as well, the reuse of tested functionality is therefore huge in such OOP systems.
However, the programmer does not need to know any of the gory implementation details at times that
need to be tackled by the receiver, e.g. if communicating with Windows OLE objects or Java objects,
one merely sends normal ooRexx messages to receivers that represent these Windows OLE objects or
Java objects. Or with other words: the message paradigm makes it easy to treat Windows OLE objects
or Java objects as if they were normal ooRexx objects as they conceptually understand ooRexx messages.
But in the end: the only thing new here is that invoking desired functionality is possible using a
simple message paradigm with the simple pattern: receiver~message
Probably because of the simplicity of the messaga paradigm it got overlooked when others started to
create OO programming languages, e.g. C++, Java, C#, Python and the like.
---rony
P.S.: The message paradigm makes a lot of dynamics possible in a simple, i.e. conceptually easy
manner, including triggering multithreading or intercepting or rerouting messages.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
