On 21.09.2017 16:41, Chip Davis wrote: > If I don't understand this issue, it won't be the first time. Just ignore me. > ;-| *Very* unlikely that you do not understand any Rexx-related issue! :-)
> It sounds as if Rony is talking about a Rexx program that, through no fault > of its own, is > dispatched on a different Rexx execution instance from the one on which it > initialized its > variables. Exactly! > (Possibly as a result of running in one of those densely woven interface > packages he's fond of > creating. :-) :) > In essence, there's now a need for a new .LOCAL, residing in the execution > space somewhere between > the classic .LOCAL and .GLOBAL. Hmm. If a Rexx object would gain an attribute "local" (let us say in the root class Object), which gets a reference to the Rexx interpreter instance's (RII) .local environment at its object creation time, then one might solve this subtle (and therefore nasty) problem: if an access is made to .local it would first lookup the object's local attribute and if not found and the current RII's .local is different, then that would be looked up next. What do you think? ---rony P.S.: In such a scenario it might be helpful for ooRexx programmers who aware that objects may run on different RIIs to query the current RII and its .local. > > On 9/21/2017 8:44 AM, René Jansen wrote: >> This sounds like a needed documentation change - the programmer needs to >> know that .local is >> indeed not global. >> >> Best regards, >> >> René. >> >> On 21 Sep 2017, at 06:38, Rony G. Flatscher <rony.flatsc...@wu.ac.at >> <mailto:rony.flatsc...@wu.ac.at>> wrote: >> >>> On 20.09.2017 17:13, Erich Steinböck wrote: >>>> Not sure if I correctly understand, but: >>>> if you're not happy about .LOCAL being local, then put your stuff into >>>> .ENVIRONMENT. >>> This is not about happiness, it is about being sure that the contract >>> between a Rexx coder and >>> the ooRexx runtime holds. >>> >>> .local is documented to be usable for the Rexx programmer to store and >>> fetch values. When a Rexx >>> object's code gets executed on a different Rexx interpreter instance, >>> .local all of a sudden >>> (and "silently") is changed and does not have the content, the Rexx >>> programmer relies to be >>> there (as that program placed values beforehand). >>> >>> As a result such Rexx code may break unexpectedly. >>> >>> Or with other words: a Rexx object is dependent on the .local object it >>> used to store values. >>> Changing that .local object without notice breaks the runtime environment >>> integrity for such an >>> object. >>> >>> ---rony >>> >>> >>> >>>> On Wed, Sep 20, 2017 at 1:14 PM, Rony G. Flatscher <rony.flatsc...@wu.ac.at >>>> <mailto:rony.flatsc...@wu.ac.at>> wrote: >>>> >>>> A Rexx interpreter instance will create a .local environment (a >>>> directory) that is local to the Rexx interpreter instance, ie. >>>> all programs being executed in it. (The .environment >>>> environment - a directory - will be available to all Rexx >>>> interpreter instances.) >>>> >>>> The .local directory contains entries for (in alphabetical order): >>>> >>>> DEBUGINPUT >>>> ERROR >>>> INPUT >>>> OUTPUT >>>> STDERR >>>> STDIN >>>> STDOUT >>>> STDQUE >>>> SYSCARGS >>>> TRACEOUTPUT >>>> >>>> Rexx programs may use .local to store all sort of data they >>>> might need while executing or coupling different Rexx programs >>>> with each other. Such Rexx programs are *dependent* on .local >>>> having all entries available to them, that they - or >>>> cooperating Rexx programs - place/store in .local. >>>> >>>> The problem: currently, when running code from Rexx >>>> packages/programs on different Rexx interpreter instances, do >>>> *not* have entries available in .local to them, if they run on >>>> a different Rexx interpreter instance! >>>> >>>> Please note: when formulating "running code from a Rexx >>>> program" any Rexx code that executes is meant, e.g. the method >>>> Rexx code of Rexx objects which happen to run on a different >>>> Rexx interpreter instances (maybe including UNINIT code). Or >>>> globally shared public routines that use .local for their >>>> purposes, and get executed in different Rexx interpreter >>>> instances, and the like. >>>> >>>> As a result, such Rexx code might behave in an undetermined >>>> manner or even break when run in a different Rexx interpreter >>>> instance, if they cannot access the .local environment they >>>> placed/stored their objects in. >>>> >>>> ---rony >>>> >>> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
