Maybe using the same name for a class method and for instance methods can end up by confuse some users.
Why not using another name for the class method, for instance "globalOptions"? It's a little redundant, yes, but it's also very clear, and it avoids confusions. Josep Maria Missatge de Rony G. Flatscher <[email protected]> del dia dc., 15 d’oct. 2025 a les 15:46: > While going to bed, I realized that I totally forgot that the > override-related options should be at the .Package class object level (just > used package instances for faster development). So the current variant has > two methods defined for the .Package class: > > - a class method named "options" that allows querying and setting the > options "OverridePackageSettings" and "CountOverride", and > > - an instance method named "options" that allows querying and setting > the options for the package instance in hand, i.e., the options "All", > "Digits", "Error", "FAilure", "FOrm", "FUzz", "Lostdigits", "NOString", > "NOTready", "Prolog", and "Trace" (these are all the options one can set > with the ::options directive). > > Yesterday's "launch.rex" sample, therefore, needs to be changed to: > > parse arg pgmName args -- parse program name and command line arguments > -- override the options of programs that get called or required from now > on.package~options("Override", "::OPTIONS ALL SYNTAX") -- set override > settings.package~options("countOverride", -1) -- override all called/required > program/package settings -- now call the program with the overridden > optionscall (pgmName) args -- run the program > > (Note: this "launch.rex" version will "globally" apply the overrides as > the "countOverride" option got set to a negative number, i.e., to "-1".) > > Usage of "launch.rex" remains the same, i.e., > > G:\test\orx\options>*rexx launch.rex test_novalue.rex* > 1 *-* say "using a variable with" novalue "which is by default fine!" > 6 *-* call (pgmName) args -- run the program > Error 98 running G:\test\orx\options\test_novalue.rex line 1: Execution > error. > Error 98.986: Reference to unassigned variable "NOVALUE". > G:\test\orx\options> > > Will now start testing and once if it looks stable enough, will commit > this version such that everyone interested may get their hands on it after > the interpreters are re-created by Jenkins and placed on < > <https://sourceforge.net/projects/oorexx/files/oorexx/5.2.0beta/> > <https://sourceforge.net/projects/oorexx/files/oorexx/5.2.0beta/>. > > ---rony > > > On 14.10.2025 22:16, Rony G. Flatscher wrote: > > Hi Jon, > > Sorry for being "mum"; however, I have been trying to get the second part > implemented and up and running the way I intended (but did not know whether > I would succeed). For a few minutes, it has been working; it still needs > thorough testing and tidying up before I would be ready to submit the code. > > Here are the coarse specifications: > > - There is a new option named "OverridePackageSettings" (default: > packageSettings default), which returns the current overridePackageSettings > as an ::OPTIONS directive string, or if a second argument is supplied, it > needs to be a string representing a syntactically correct ::OPTIONS > directive which then gets used to set the override packageSettings from > then on; this can be changed at runtime dynamically at any time repeatedly > > - There is a new option named "CountOverride" (default: 0), which > returns the current "countOverride", and if a second argument is supplied, > it needs to be a number with the following implications (can be changed at > anytime repeatedly): > > - 0 ... no overriding takes place (default setting) > > - +n (positive number): overriding takes place exactly n times and > then halts > > - -1 ... overriding takes place constantly (in previous discussion > meant for "global override") and can only be stopped by setting the > value > explitly to 0 (.context~package~options("count",0)) > > This will allow at runtime to turn on package settings override > dynamically (e.g. for debugging). > > This should e.g. allow for a little Rexx launcher, that would allow Walter > et.al. to invoke any program with something like "::options all syntax" > or "::options digits 20" to override all program option settings > intentionally ("launch.rex"): > > parse arg pgmName args -- parse program name and command line arguments > -- override the options of programs that get called or required from now > onpkg = .context~package -- get package objectpkg~options("Override", > "::OPTIONS ALL SYNTAX") -- set override settingspkg~options("count", 1) -- > just override settings once for the next called/required program > -- now call the program with the overridden optionscall (pgmName) args > -- run the program > > Here a program that would run as long as the novalue condition is not set > ("test_novalue.rex"): > > say "using a variable with" novalue "which is by default fine!" > > Running the "test_novalue.rex" program as is with its output: > > G:\test\orx\options>*rexx test_novalue.rex* > using a variable with NOVALUE which is by default fine! > G:\test\orx\options> > > Running "test_novalue.rex" with "launch.rex" above would look like this > and generate the following output: > > G:\test\orx\options>*rexx launch.rex test_novalue.rex* > 1 *-* say "using a variable with" novalue "which is by default fine!" > 8 *-* call (pgmName) args -- run the program > Error 98 running G:\test\orx\options\test_novalue.rex line 1: Execution > error. > Error 98.986: Reference to unassigned variable "NOVALUE". > G:\test\orx\options> > > If the "count" option was set to "-1" then all subsequently called or > required programs would get their package options overridden as well. > > --- > > The third part (TBD, maybe Gil can lend a hand there, which would be > really of great help) would then be to implement the ability for the > discussed switches for the rexx launchers (rexx[.exe], rexxhide[.exe], > rexxpaws[.exe]): > > options ::= (-o | --override | -g | --global-override) ("string" | > @<filespec>) > > Ad "string": this must be formatted as a single, syntactically correct > "::OPTIONS" directive, without a semi-colon (;), carriage return (CR, > "0d"x) or linefeed (LF, "0a"x) to be seen acceptable. > > --- > > After testing further and tidying up I would also try to reword the > documentation, trying to avoid the problems that Jon has thankfully pointed > out, with the request to give feedback or improvements for it, once done! > > ---rony > > > > On 13.10.2025 16:57, Sahananda wrote: > > Hi Rony, > > It is really tricky expressing things clearly and it seems to me that this > sentence describes something that can be used several ways and thus is > really complicated. I'm now not sure whether the verb should be Set, > Modify or Override, and if I have understood you correctly, then until we > see the behaviour of the finished object this will remain unclear, and it > may be that even at method invocation time, we don't know whether the > operation being performed is a set, a modify or an override as that is > dependant on what follows and whether new programs or packages inherit > these options. > > To me, this is the flavour of the three words > > - SET - This assigns a value to the option, either an initial one or a > replacement one. The value can subsequently changed by setting again > - MODIFY - This assigns a new value replacing an extant value. The > value can subsequently be changed by modifying again > - OVERRIDE - This is assigning a new value whilst remembering the old > (or perhaps original) value. The OVERRIDE can be undone somehow and either > the previous or original value will be reinstated. I'm not clear whether > this is a push/pop. > > None of them seem to exactly describe the mechanism that you describe > (turning off the override) > > I wonder if anyone else can take a stab at it? > > Jon > > > On Mon, 13 Oct 2025 at 14:09, Rony G. Flatscher <[email protected]> > wrote: > >> Hi Jon, >> On 13.10.2025 14:07, Sahananda wrote: >> >> Sorry, there was a typo. In my suggested sentence, the first 'set' is >> redundant as what is being set is called the 'package options', not the >> 'set package options'. >> >> The first part of the sentence should therefore read: >> >> *This method retrieves the current package options,* >> >> I have difficulty with the rest of the sentence as I am not sure what you >> are saying. Perhaps it would be better as two sentences: >> >> *This method retrieves and optionally sets the current package options. >> The package options may also be set explicitly using the ::options >> directive.* >> >> I'm not sure whether the word 'modifies' should replace the word 'sets'? >> If (and I think this is the case) there will always in every circumstance >> be a previous value to the package options when this method is called, I >> think '*modifies*' is better here. If there is some circumstance where >> this method can be used to initialise the package options (and I don't >> think that is possible) then imho '*sets*' would be clearer. >> >> Again, I'm still not sure how the adverb '*explicitly*' modifies the >> meaning in this context. Perhaps if you said a couple of sentences about >> that I could venture an opinion. >> >> Again, I hope this is helpful, >> >> Yes, very much so, and thank you very much for taking the time! >> >> Maybe a few more infos after reading your thoughts: this 'options' method >> without argument returns a string formatted as an ::OPTIONS directive >> showing all options in effect for the package. In addition it allows to >> query and set any option that can be listed on the ::OPTIONS directive, >> whereby always the value at method invocation time gets returned. >> >> However, this method is also meant for allowing for defining the package >> settings that should be used to override the package settings when loading >> programs/packages which then determine the package settings that should be >> in effect. To make this even more flexible there is an idea of turning >> on/off the overriding behaviour not only with a switch, but even allowing >> to optionally define the number of overrides that should take place, >> including "infinity". This is still in infant stage, but eventually this >> should become available (currently implementing that part). >> >> Not sure whether that clarifies it, as it is work in progress (WIP) and >> cannot be tested yet. (Once that part works one could use that >> infrastructure then to allow for supplying override options when starting a >> Rexx program.) >> >> HTH >> >> ---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
