The idea of first implementing the options method (as an instance method) is to become able to
experiment with changing options at runtime.
Then the step of allowing an environment variable or a command line option would enter the field Gil
has brought up with PROLOG/NOPROLOG, with Josep Maria's idea of a class method. As Gil writes, if a
program/package is loaded, the prolog code block gets run by default, unless the program/package
contains an "::option noprolog" option. If allowing overrides at startup or globally for all loaded
programs/packages, then it is necessary to a) record the override options, b) find the location
where to add them to the loading program/package (before the prolog code block gets run). The
override options for loading programs/packages need to be defined at the class level, allowing
defining, querying, and removing these override options at runtime as well, to keep everything truly
dynamic, which would allow for testing that feature before making it available via the environment
or startup option.
An indication that an option is to be fetched from a file, one additional thought: in Java, it is
possible to configure the JVM at startup, for which, over time, there has been a wealth of options
defined, which sometimes gets out of hand. So the Java people introduced the ability to define any
number of startup options in a file which gets marked/indicated with an at character (@) followed by
the file name, e.g., "my_options" would be indicated as "@my_options", cf.
<https://docs.oracle.com/en/java/javase/17/docs/specs/man/java.html>. So, going this route instead
of "file:<filespec>", we could use "@<filespec>".
Ad format of the environment, command line, or file: here I would suggest using the ::options
directive itself. The reason being that programmers dealing with options are aware of the ::options
directive and can formulate and understand therefore ::options definition. In case multiple
::options are desired, the programmer can do so by delimiting the ::options directives with
semi-colons (end-of-clause), such that the options string would be a proper, testable ooRexx program.
Ad short and long option names: from the Unix world, options start by convention with a dash and
used to be as short as possible to save programmers typing. Sometimes the option names being single
characters would not indicate well enough their intent, so over time an optional (self-describing)
long format for options became customary (introduced with two dashes, --), which the Java world also
has embraced. Hence, suggesting for "-o" a long format "--options", for "-go" a long format
"--global-options".
What do you think?
---rony
On 04.10.2025 08:57, Josep Maria Blasco wrote:
I don't have strong opinions about whether this should be or not a method of
the package class. Indeed, and since what it will be governing is how packages
are loaded, it might be the nucleus of a possible future loader class, and that
would most probably deserve its own separate class, which most probably
should be a singleton, by the way.
Josep Maria
Missatge de Gilbert Barmwater via Oorexx-devel <[email protected]> del dia dv., 3
d’oct. 2025 a les 20:53:
That's an interesting thought although I can't think of another class that
has such a concept.
Gil
On 10/3/2025 2:45 PM, Josep Maria Blasco wrote:
Maybe the "options" method Rony is suggesting has to be a class method,
i.e.,
an instance method of the Package class, not of the package class instances?
That way, one would be able to say "from now on, package loading will be
governed by the following rules", which is the original goal of the whole
discussion.
If "options" is a class method and I understand things correctly, the
problems
you mention should disappear.
Josep Maria
Missatge de Gilbert Barmwater via Oorexx-devel
<[email protected]> del dia
dv., 3 d’oct. 2025 a les 18:49:
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
