I don't have strong opinions about whether this should be or not a method of the package class. Indeed, and since what it will be governing is how packages are loaded, it might be the nucleus of a possible future loader class, and that would most probably deserve its own separate class, which most probably should be a singleton, by the way.
Josep Maria Missatge de Gilbert Barmwater via Oorexx-devel < [email protected]> del dia dv., 3 d’oct. 2025 a les 20:53: > That's an interesting thought although I can't think of another class that > has such a concept. > > Gil > On 10/3/2025 2:45 PM, Josep Maria Blasco wrote: > > 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 > [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 >
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
