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.
Any thoughts?
Gil
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
--
Gil Barmwater
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
