On 30.09.2025 19:57, Gilbert Barmwater via Oorexx-devel wrote:
Having had some time to think about this, I have the following proposed design
for discussion.
1) I very much like the idea of an environment variable - I would call it REXX_OPTIONS to be
consistent with the other one, REXX_PATH. This has the advantage of allowing a one-time setting,
if desired, and removal of the need to type the value for every execution of a program with the
possibility of mis-typing it. I would propose that the entire "line" to be appended be specified
in rexx_options, i.e. '::options all syntax' for example. This would then allow addition of a
::requires directive instead should one need to "add" multiple lines to the end of the target
program. (The multiple lines would be placed in a separate file and the ::requires would name that
file.)
2) Specifying a switch ( /O or -O ) on the rexx command gives the user control on every execution
if the "line" is to be added (or not). I would not consider it an error if the "O" switch was
specified but rexx_path was undefined; this would be equivalent to execution without the "O" switch.
One might argue that this design requires a two step process as compared to specifying
"everything" on the command which is a single step. While true, I believe the potential usage for
this feature would be multiple executions of the command with the same "options" so being able to
specify those "options" once would be beneficial.
I do not think the implementation should be too difficult (I have experience adding a switch to
rexx.exe) with the more challenging part being locating and getting the target program source into
a buffer where the "line" can be appended. The buffer would then be executed by RexxStart just as
is done when the "E" switch is present with a program string.
It would be possible to "blindly" append an ::options statement to the end as ::option directives
can be given multiple times and the last one wins. This is done by tracetool.rex (cf. net-oo-rexx
package) which appends an ::option statement to denote the desired global trace option for creating
a tracelog.
There is one case where this is not possible: if a program is compiled with rexxc one cannot tamper
with the source code as it is not available.
---
AFAICT the options are registered against the package which can be used to query all set options.
What is missing there are (protected) setters which would allow for changing the initial settings at
runtime which sometimes would be more than helpful as the case of Walter shows. Studying the
fundamental Package class one could use importedPackages to analyze (and if made possible) and to
change the global options settings there as well, if one wrote such an ooRexx program (e.g.
processing all available packages in the prolog and setting the options there).
So a question in this context would be whether it was o.k. to add setters to the package's option
attributes "digits", "form", "fuzz", "trace"? And add some "condition" method to set/reset the
condition related settings (like "all syntax" or "all condition"), if that is possible to have
immediate effect at runtime.
---
If one wishes to set the options to be used for programs that are to be required/called, all of the
options (including "prolog" or "noprolog") should become settable. Maybe having a runtime "options"
object in addition that defines the defaults for loading/requiring programs could be used, such that
the defaults for loading new programs could be changed by changing such a default "options" object?
---rony
On 9/29/2025 8:02 AM, Rony G. Flatscher wrote:
One more idea: as ooRexx starts out with predefined options values (like "digits 9", "trace
normal", ...) which currently can be changed statically per program/package by adding ::options
statements, it should be possible to define those "predefined options" at startup. E.g.,
something like (borrowing from Regina)
* rexx someRexxProgram -o "options string" somePgm args ... somePgm and each
program executed
will get its options changed to "options string"
* rexx someRexxProgram --options="options string" somePgm args ... somePgm
and each program
executed will get its options changed to "options string"
* rexx someRexxProgram -op somePgmWithOptionsSet.cls somePgm args ... somePgm
and each program
executed will get its options changed to all ::OPTIONS in
"somePgmWithOptionsSet.cls"
or an environment variable like OOREXX_OPTIONS, where each program executed will get its options
changed to OOREXX_OPTIONS.
This would allow Walter's requirement to be easily applied without the need to change any
program, something like 'rexx -o "ALL SYNTAX" somePgm [args]'
---rony
On 28.09.2025 21:46, Rony G. Flatscher wrote:
On 28.09.2025 15:04, Hobart Spitz wrote:
IMHO, yes. It keeps with the philosophy of general flexibility and "letting the programmer do
what they want when they want" even if we can't think of a reason right now.
Thank you for your feedback, Hobart!
Any other thoughts?
---rony
OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk
(JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while
Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon.
REXX is the new C.
On Sun, Sep 28, 2025, 05:49 Rony G. Flatscher <[email protected]> wrote:
ooRexx being a dynamic language usually allows for defining, e.g. classes
statically with
directives, but also dynamically at runtime instantiating .class (and
creating and
assigning methods
and the like).
The ::options directive has become quite powerful and it would be helpful
to be able to a)
query all
package's current settings and b) allowing to change the (::options
related) package
settings at
runtime ("dynamic"). (Maybe a proper Options class may be helpful which
allows for
interrogating and
setting options.)
This may help in situations like using (maybe older) Rexx programs for
which some settings
should be
changed (like "any syntax", but also "trace ..." comes to mind, etc.).
Would that be seen as a desired improvement?
---rony
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
