Hi Josep Maria,
On 28.02.2023 16:32, Josep Maria Blasco wrote:
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).
"package" represents at runtime the program in which an invocation currently executes and can be
fetched using ".context~package".
The .Package class' importedPackages method supplies the currently available "imported packages" as
an array. Each "::requires someProgram" and each "call someOtherProgram" will cause entries to be
added and access to all public classes and public routines of all such imported packages is
maintained thereby.
*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.
Well, that is not correct in ooRexx! A "routine" in ooRexx can represent a fully fledged program
that may contain directives and as a result will also make all its public routines and public
classes directly available to the caller.
:)
So, to reply to your question: (1) yes, the behaviour of CALL and :;REQUIRES
/is/ different
If I understand your reasoning correctly, you suggest that CALL and ::REQUIRES behave differently
assuming that one can only CALL a procedure or a routine? If that is the case then this assumption
is not correct.
Cheers
---rony
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
