> As a little teaser, if interested, just look-up the ooRexx runtime objects > named .input, .output and .error.
Aren't those just monitor objects? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ 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
