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
