On Fri, Jul 18, 2008 at 1:39 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote: > On Fri, Jul 18, 2008 at 9:41 AM, Rick McGuire <[EMAIL PROTECTED]> wrote: >> We had a discussion a while back about the adding an implementation of >> a class that will retrieve the current execution context via the >> environment variable .CONTEXT. This now implemented in trunk, and >> here's the initial set of things I allow you to access via .CONTEXT: > > Looks good Rick. > > ... >> - variables Returns a supplier that allows iteration through all of >> the current variables. This only returns top-level variables (i.e., >> simple variables and stems). Compound variables, of course, can be >> accessed by using stem object values associated with a stem variable. > > By top-level variables, you just mean not compound variables, right? > In other words arrays, directories, etc.. are all top-level?
arrays, directories, etc. are not VARIABLES, those are VALUES. For example, a = .array~new d = .directory~new s = "Fred" stem.1 = "Rick" stem.2 = "Mark" The variables that will be returned are "A", "D", "S", and "STEM.". The value of "STEM." is a .stem object. The values of the simple variables will be whatever object they're assigned to. > >> Some notes. >> >> 1) Currently, these are "read-only" values. I'm not sure I'm >> prepared to start down the slipperly slope of allowing this object to >> be used to changes settings/variables. I'm not totally opposed to it, >> but I'm erring on the side of caution for now. This class makes it >> fairly easy to add those capabilities in the future if we decide this >> would be a good thing. > > I think that is a good plan. Let's not start down the slippery slope > until after 4.0.0. Maybe later we can create a sandbox area where you > implement the function of allowing the settings / variables to be > changed. > > Then Moritz, myself, and maybe some others that are interested could > build from that sandbox to play around with it. To see if we shoot > ourselves in the foot or not. <grin> > >> 2) The object returned by .CONTEXT is only valid as long as the >> context it was retrieved from is active. Invoking any of the >> RexxContext methods will raise an error if that context has been >> terminated. > > Basically, this would mean within the scope of a method or routine? > Or is the context a whole program? Say you had something like > > contextObj = .Context > t = .Talker~new > t~passObj(contextObj) > > context = t~passBackObj > ? context good? > > ::class 'Talker' > ::method passObj > use strict arg myContext > ? myContext good? > > ::method passBackObj > context = .Context > return context > > Is the .Context in a method just good withing that local scope of the > method? Is the .Context at the top-level scope of the program, not > good within the method? You can pass a context object FORWARD, but never BACKWARD. Thus call foo .context will pass my context object to an entity I call, and it can retrieve information from it. For example, the variable dumper that Les demoed at the Symposium that required interpret to execute can be done much easier by doing call variableDumper .context The variableDumper routine can access the object via USE ARG just like any other object and retrieve the variables. However, you cannot do this: return .context As soon as the return executes, this context will "go stale", so any attempt on the part of the caller to use this will result in an error. > > Also, you had talked about this .Context object being available to > external functions written using the native API. (I think you did, > maybe I don't remember correctly.) How would you access it? It is > not the context object that is passed automatically to the REXX_METHOD > methods is it? (Or is it?) A lot of the methods implemented in the RexxCallContext API have directly analogs to what's available via .context. For example GetAllContextVariables() and GetContextDigits(). There were certain things that you could do from native code that you couldn't do from Rexx code. Of course, SetContextVariable() is still one place where there's a capability mismatch. There's one other slippery slope I've sidestepped, and that's the ability to request access to your caller's context. There are a number of nasties that can occur if you try to do that, including opening some potential security holes. I see there's a big difference between deciding to give a called routine access to all of my variables vs. having it just decide to grab it. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
