> > Am 10.01.2022 um 15:22 schrieb Seymour J Metz <sme...@gmu.edu>: > > >> >> As a little teaser, if interested, just look-up the ooRexx runtime objects >> named .input, .output and .error. > > Aren't those just monitor objects? Yes. They monitor stdin, stdout and stderr (all three are streams that could also be redirected from to the Rexx program). ooRexx will use the monitors itself rather than directly interacting with the stream objects.
So say statements will cause the string to be sent to .output which then will forward the message with string argument (if any) to .stdout. If using lineout or charout to write an error message to „stderr“ the message gets sent to .error which forwards the message to its monitored .stderr stream. If one knows that it is easy to e.g. create error logfiles on a daily basis if running a 7/24 ooRexx program: you merely replace the destination of the .error monitor to a logger object you create which would create a file like „error-20220110.log“ and forward each received say/lineout/charout message to that file object (which is an instance of the ooRexx class .stream). Then if midnight is up, the logger object closes that log file and creates a new one like „error-20220111.log“ to which messages get forwarded. This way all error messages get logged and can be inspected. The nice thing about this is that no REXX program needs to know or realize that! —- Another application possibility is employed by BSF4ooRexx: this external function package makes it easy to host REXX and ooRexx scripts that get executed with ooRexx (and it is even possible to supply Java objects the REXX/ooRexx scripts wish to interact with). Usually this is done by Java/NetRexx/Kotlin/Grooivy/… with the help of the Java scfripting framework which supplies Java objects representing stdin, stdout and stderr. Exploiting the ooRexx monitor objects .input, .output and .error BSF4ooRexx transparently replaces the destination objects of these monitors, intercepting all messages and forwarding them to the appropriate Java objects. And the best: the REXX/ooRexx programs do not even need to know that, which alleviates the programmers. So they even do not need to know how this „magic“ gets realized under the hood. Sheer power! Easy to use as no one needs to code an extra line of code for that (important) purpose. :) Again, this is only possible in such an easy (in this case even totally transparent) manner, because ooRexx implements and uses the message paradigm. And BTW BSF4ooRexx does one more thing: by default it prefixes the streams e.g. with „REXXout>“, „REXXerr>“ such that all REXX/ooRexx related interactions with the streams can be quickly identified in Java log files which is extremely helpful for locating them (if Java logging is enabled long running programs can create huge log files). —-rony Rony G. Flatscher (mobil/e) > > ________________________________________ > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of > Rony G. Flatscher [rony.flatsc...@wu.ac.at] > Sent: Monday, January 10, 2022 7:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Port of ooRexx to z/OS? (Re: Ad NetRexx (Re: Ad programming > features (Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS > >> On 10.01.2022 05:28, David Crayford wrote: >>> On 9/1/22 11:22 pm, Rony G. Flatscher wrote: >>> On 09.01.2022 03:19, David Crayford wrote: >>>> On 9/1/22 2:15 am, Rony G. Flatscher wrote: >>>>> On 08.01.2022 01:52, David Crayford wrote: >>>>>> On 7/1/22 7:53 pm, Rony G. Flatscher wrote: > > ... cut ... > >>>> Number 7 on my list is support for OO which implies message passing. >>> Well, this does not mean that the programming language supports the message >>> paradigm. If it did it >>> would have an explicit "Message" class (like there are explicit classes >>> like "Object", "Class", >>> "Method" and the like), hence messages are not FCOs. Compare this to >>> languages like SmallTalk or >>> ooRexx. >>> >>> Maybe it is easier to grasp some of the ramifications by looking at the >>> popular fluent pattern >>> (https://secure-web.cisco.com/16gHuUSvm6wTt36qDHrbk52jx7cBfrMxkFy9KdL4OA5teVngp8Mpxa3-ScxQQj6e8NG8rc5Poicg4agf5YtCC7n9giLhoKsCYDHGyaSIplNNZYJpoOiaHTibhkaNKJDd5kMrMIsI7iMuEcfUcSxBtXuq80eRv-jsiH3bt0FEkf2whHXX3X9KAku-TVgGXniJyaOhg4rTanyB_YmPOXyiZKSyA0kL3i8i8SnOVK3RaQ0jMgetCj6diuu61cSmSouZ3VeteLv7HyTfu8lDFu0g2esJUbMSz_nitJ1YkcB_d9OyZvpJb9WB0O6E9S8kPfLuixlWnfmgLwpxGWgYK0xZZcsF18e3TiQuoePIwYl2HE7LOHxHE6lHW7jaAEwPD5ehgtPaIjK7Wqqqbp-m7skw8ruTvJkYUOXXAc5U7m6oGqnt_ugEow8VOV6C1QQlhfDME/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFluent_interface) >>> which needs to be explicitly programmed in >>> languages that do not support the message paradigm, but is "freely" ;) >>> available in languages like >>> Smalltalk and ooRexx. >> >> I'm familiar with fluent APIs. I've been coding C++ and Java for over 25 >> years. They don't need an >> explict "Message", "Object" or "Class". In Java every object is a subclass >> of Obect. C++ is a >> multi-paradigm language so doesn't require that. >> To write a fluent interface in C++, Java, JavaScript just return "this" from >> the class method or >> member function. In Lua or Python return self. Then you can chain together >> method calls. This is >> meat a potatoes stuff in all of the languages I listed. > > Yes, one has to explicitly change the method signatures in strictly typed > languages to return the > object for which the method executes and one must supply the appropriate > return statement in each of > these methods, which is fine. > > --- > > In ooRexx however, you do not have to explicitly code "return self" in > methods in order to use > methods of a class fluently. It even does not matter whether a method returns > the proper object > (referred to with the variable named self in the fluent method) or has no > return value at all! If an > ooRexx programmer wants to use an object's/value's/instance's methods > ("behaviour") fluently, he can > do so independent of whether the method returns the proper object or not. > > It is this flexibility (if needed) that is available by design, because of > the full implementation > of the message paradigm, relieving the programmers of burdens they must > undergo in many popular > programming languages, and all must apply properly the pattern. > > --- > > There are other aspects, abilities that ooRexx possesses that other popular > programming languages > lack because of the message paradigm ooRexx implements. As a little teaser, > if interested, just > look-up the ooRexx runtime objects named .input, .output and .error. As > harmless as they may look, > it is incredible which power they make available to programmers if need be. > But that would be > another story ... > > ---rony > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
