On further testing and analysis, the following can be observed and demonstrated
with this small program:
say .context~name
parse arg dynamicRequires
if dynamicRequires="" then bCall=.true
else bCall=.false
say "hello world, it is:" .datetime~new
o=.test~new
say "o:" o ".test:" .test
say "---"
say "thisPackage~options :" .context~package~options
say
say ".package~globalOptions('o'):" .package~globalOptions('o')
"countOverrides:" .package~globalOptions('c')
say "---"
say
say "about to do a: call test2 ..."
if bCall then
call test2
else -- dynamic requires
.context~package~addPackage(.package~new("test2"))
say "---"
say
say "about to do a: call test3 ..."
if bCall then
call test3
else -- dynamic requires
.context~package~addPackage(.package~new("test3"))
say "--- done."
::class test
::method init class
say .line":" .context~name
::method activate class
say .line":" .context~name
::options digits 14
*::options prolog noprolog*
The above program gets invoked from the command line like "rexx test.rex".
This program/package defines "::options prolog noprolog" which should inhibit the execution of the
prolog, which would be what used to be called the "main program", the code body before the first
directive or the end of the program. Therefore, only the class-related initializations should take
place for "test.rex", but no code in the prolog should get executed (hence, there would be output
from the prolog part of the test, and no calls to test2 or test3 at that point in time).
Looking at PackageClass::runProlog(), the prolog gets only executed if it is enabled. So in this
case, it should not be invoked= PackageClass::runProlog() will, in any case run
PackageClass::install(), which allows, among other things, for initializing the classes' init and
activate class methods. However, PackageClass::install() in this case will also run the prolog code,
independent of whether isPrologEnabled() is set or not!
When parsing and readying a program LanguageParser::installPackage() gets invoked, which
unconditionally invokes PackageClass::install(), which in turn will also run the prolog code.
The question: Is this to be expected, working as designed?
---rony
P.S.: If running the above program using dynamic requires, the behavior of not running the prolog is
as expected for test2 and test3 (if it got set to noprolog for test2 and test3): classes get
initialized (class methods init and activate run), but the prolog of the programs/packages does not
get executed as intended. So, there may be a rule that a prolog is only a prolog if the
program/package gets required? And, if a program/package gets invoked with CALL or as a command,
then the prolog code body is not regarded to be a prolog, but a plain program that needs to get
executed in any case?
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel