Maybe the global case could also be handled at the command line level.
For example, assuming that
rexx -o "options" program
would pass options "options" to "program" and to "program" alone,
rexx -go "options" program
(""go" for "global options") would pass options "options" to "program", and
to all the packages required by "program" or loaded via loadPackage.
Josep Maria
Missatge de Rony G. Flatscher <[email protected]> del dia dc., 1
d’oct. 2025 a les 12:07:
> 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
>
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
