Just a heads up based on my experience w/ the Package class. Creating an
instance of .package ALWAYS* causes the code in it to execute
immediately. This includes both the New method and the LoadPackage
method (and probably LoadLibrary). *If the target file or source array
has an ::option noprolog, then the prolog code, if any, is NOT
immediately executed but all directives are immediately processed. So
it seems problematic to me to define an Options method on that class to
change how the package is going to behave since it will be "after the
fact" so to speak.
This behavior was a bit of a surprise to me initially but it makes sense
in the context of being able to dynamically ::requires other packages at
runtime. You'll notice the .package class has NO method similar to the
Call method of .Routine. (One can create a .routine from the prolog via
the Prolog method which can then be executed.)
Gil
On 10/3/2025 5:49 AM, Rony G. Flatscher wrote:
In order to systematically try to implement this feature, I would
suggest implementing the method "options" for Package first and then
analyzing whether everything works as expected. If that works out, the
next step would be to define the specs for the environment variable
and command line switches (this includes whether, and if so, how to
define options/fileContent that should be used for the initial
program/package, or globally from that moment on for all
programs/packages that get loaded).
So here is a suggestion for the description of the suggested OPTIONS
method for the Package class:
OPTIONS( [optionName [, newValue]])
Returns a directory with the values of all currently set options
for the package. If the optional argument "optionName" is
supplied, it returns the current setting. If the optional argument
"newValue" is supplied for "optionName", then "newValue" replaces
the current value for the package.
"optionName" can be one of (only the first signifcant letters need
to be supplied as argument, depicted in uppercase):
* Digits
returns the current number of digits (default: 9)
* FOrm
returns "ENGINEERING" or "SCIENTIFIC" (default: "SCIENTIFIC")
* FUzz
returns the current number of FUZZ digits (default: 0)
* Handlecondition (default: "ERROR CONDITION FAILURE
CONDITION LOSTDIGITS CONDITION NOSTRING CONDITION NOTREADY
CONDITION NOVALUE CONDITION")
returns a string denoting how conditions get handled
* Prolog (default: "PROLOG")
returns "PROLOG" or "NOPROLOG"
* Trace (default: "NORMAL")
returns "NORMAL | ALL | COMMANDS | ERROR | FAILURE |
INTERMEDIATES | LABELS | OFF | RESULTS"
Changing "optionName" to "newValue" (only the first significant
letters need to be supplied as argument, depicted in uppercase)
* Digits, nrDigits
nrDigits>0
* FOrm, "Engineering" | "Scientific"
* FUzz, nrDigigs
nrDigits>=0
* Handlecondition, (All | Error | Failure | Lostdigits |
NOString | NOTReady | NOValue "Condition" | "Syntax")+
Note 1: using ALL will set ERROR, FAILURE, LOSTDIGITS,
NOSTRING, NOTREADY, NOVALUE to "CONDITION" | "SYNTAX"
Note 2: it is possible to have multiple definitions such
that one could use ALL for the default handling, and
define specific handling options for ERROR, FAILURE,
LOSTDIGITS, NOSTRING, NOTREADY, NOVALUE if need be; in
case of conflict, the last definition prevails
Note 3: the settings of the conditions HALT, NOMETHOD,
SYNTAX, and USE cannot be changed
* Prolog, "Prolog" | "Noprolog"
* Trace, Normal | All | Commands | Error | Failure |
Intermediates | Labels | Off | Results
How about protecting this method such that a security manager can be
used to protect access to this method, if need be?
Are there any stumbling blocks, side effects one needs to be aware of?
Any thoughts, comments, ideas?
---rony
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
