Maybe the "options" method Rony is suggesting has to be a class method, i.e., an instance method of the Package class, not of the package class instances? That way, one would be able to say "from now on, package loading will be governed by the following rules", which is the original goal of the whole discussion.
If "options" is a class method and I understand things correctly, the problems you mention should disappear. Josep Maria Missatge de Gilbert Barmwater via Oorexx-devel < [email protected]> del dia dv., 3 d’oct. 2025 a les 18:49: > Just a heads up based on my experience w/ the Package class. Creating an > instance of .package ALWAYS* causes the code in it to execute immediately. > This includes both the New method and the LoadPackage method (and probably > LoadLibrary). *If the target file or source array has an ::option noprolog, > then the prolog code, if any, is NOT immediately executed but all > directives are immediately processed. So it seems problematic to me to > define an Options method on that class to change how the package is going > to behave since it will be "after the fact" so to speak. > > This behavior was a bit of a surprise to me initially but it makes sense > in the context of being able to dynamically ::requires other packages at > runtime. You'll notice the .package class has NO method similar to the > Call method of .Routine. (One can create a .routine from the prolog via > the Prolog method which can then be executed.) > > Gil > On 10/3/2025 5:49 AM, Rony G. Flatscher wrote: > > In order to systematically try to implement this feature, I would suggest > implementing the method "options" for Package first and then analyzing > whether everything works as expected. If that works out, the next step > would be to define the specs for the environment variable and command line > switches (this includes whether, and if so, how to define > options/fileContent that should be used for the initial program/package, or > globally from that moment on for all programs/packages that get loaded). > > So here is a suggestion for the description of the suggested OPTIONS > method for the Package class: > > OPTIONS( [optionName [, newValue]]) > > Returns a directory with the values of all currently set options for the > package. If the optional argument "optionName" is supplied, it returns the > current setting. If the optional argument "newValue" is supplied for > "optionName", then "newValue" replaces the current value for the package. > > "optionName" can be one of (only the first signifcant letters need to be > supplied as argument, depicted in uppercase): > > > - Digits > returns the current number of digits (default: 9) > > - FOrm > returns "ENGINEERING" or "SCIENTIFIC" (default: "SCIENTIFIC") > > - FUzz > returns the current number of FUZZ digits (default: 0) > > - Handlecondition (default: "ERROR CONDITION FAILURE CONDITION > LOSTDIGITS CONDITION NOSTRING CONDITION NOTREADY CONDITION NOVALUE > CONDITION") > returns a string denoting how conditions get handled > > - Prolog (default: "PROLOG") > returns "PROLOG" or "NOPROLOG" > > - Trace (default: "NORMAL") > returns "NORMAL | ALL | COMMANDS | ERROR | FAILURE | INTERMEDIATES | > LABELS | OFF | RESULTS" > > Changing "optionName" to "newValue" (only the first significant letters > need to be supplied as argument, depicted in uppercase) > > > - Digits, nrDigits > nrDigits>0 > > - FOrm, "Engineering" | "Scientific" > > - FUzz, nrDigigs > nrDigits>=0 > > - Handlecondition, (All | Error | Failure | Lostdigits | NOString | > NOTReady | NOValue "Condition" | "Syntax")+ > Note 1: using ALL will set ERROR, FAILURE, LOSTDIGITS, NOSTRING, > NOTREADY, NOVALUE to "CONDITION" | "SYNTAX" > Note 2: it is possible to have multiple definitions such that one > could use ALL for the default handling, and define specific handling > options for ERROR, FAILURE, LOSTDIGITS, NOSTRING, NOTREADY, NOVALUE if need > be; in case of conflict, the last definition prevails > Note 3: the settings of the conditions HALT, NOMETHOD, SYNTAX, and USE > cannot be changed > > - Prolog, "Prolog" | "Noprolog" > > - Trace, Normal | All | Commands | Error | Failure | Intermediates | > Labels | Off | Results > > How about protecting this method such that a security manager can be used > to protect access to this method, if need be? > > Are there any stumbling blocks, side effects one needs to be aware of? > > Any thoughts, comments, ideas? > > ---rony > > -- > Gil Barmwater > > _______________________________________________ > 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
