Hi Rony, Replying now to your other question. As you'll see, it's an interesting one.
Missatge de Rony G. Flatscher <rony.flatsc...@wu.ac.at> del dia dl., 27 de febr. 2023 a les 18:59: > (snip) > > Ad requires directive: the supplied program name should be called by the > Rexx instance on behalf of the program the very first time and follow > therefore the existing call semantics to not cause surprises? (If the same > program gets required by additional programs in the Rexx instance then the > program does not get called a second time, but its now known public > routines and known public classes are made immediately available to that > program.) > > Are you sure that requiring a program is not behaving like calling that > program? > > ---rony > Well, once more we have an incoherence between the documentation and the behaviour of the interpreter. Rexxref 3.3 says: "If you specify the PUBLIC option, the class is visible beyond its containing Rexx program *to any other program that references this program with a ::REQUIRES directive*. If you do not specify the PUBLIC option, the class is visible only within its containing Rexx program. All public classes defined within a program are used before PUBLIC classes created with the same name" (emphasis is mine). Now please create a file called program.rex, and put the following inside: Say "Program called." ::Class C Public ::Method M Say "Method M called." >From another file (say test.rex), please Call program. You'll be able, from inside test.rex, to create an object of the C class, and to invoke its M method. *But you should not have been able to*. You have not *::required* the file, but *called* it. And the documentation is very clear in this respect: the class will be visible *to any other program that references this program with a ::REQUIRES directive.* Not to any other program that has *called* the file. ::REQUIRES implies, in some sense, a CALL -- of its prolog. But CALL should *not* imply a ::REQUIRES. Now enter trace somewhere inside of test.rex, and try say .context~package~importedpackages~items --> 0 Now add a ::REQUIRES program directive to test.rex, call it again and trace: say .context~package~importedpackages~items --> 1 say .context~package~importedpackages[1]~name --> D:\test\program.rex (my location) Without ::REQUIRES, the C class is somehow imported, but the package is not. My impression is that (according to the docs), *the C class should have not been imported at all*. The creation of an object of the C class should have *failed *(syntax error). *Besides.* ::REQUIRES is a way to extend our vocabulary: after a ::REQUIRES (or its dynamic counterpart addPackage), we can use all the new public classes and routines that the imported package defines. CALL is *not* designed to extend our vocabulary. It's a way to invoke a procedure or a routine. So, to reply to your question: (1) yes, the behaviour of CALL and :;REQUIRES *is* different (see .context~package~importedpackages~items); (2) yes, the behaviour of CALL and ::REQUIRES *should be* different (if the interpreter worked as described in the docs), and, to finalize, (3) my impression is that CALL and ::REQUIRES are designed to fulfil very different needs, and therefore their behaviour, per force, has to be different. The fact that *the prolog* of a ::REQUIRED file is, in practice, almost CALLed (although only once), and the fact that the external files search algorithm is (practically) the same in both cases (i.e., excepting the ".cls" extension) should not lead us to believe that CALL and ::REQUIRES have more things in common than they really have. Josep Maria
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
