Perhaps this explanation might help. Rexx uses the concept of variable pools to hold sets of variables/values. There can be multiple variable pools in use at the same time. In a classic Rexx (and ooRexx) program new variable pools are created when you use the PROCEDURE keyword on a function definition or when you call an external Rexx function contained in another file. This is how the concept of variable scoping is implemented. So for non-oo scripts you don't see a lot of this going on.
Variable pools also have the concept of parent/child relationships. Although there are exceptions, most variable pools are either a parent or a child of another variable pool. When you "expose" a variable what you are really doing is granting access to the current variable pool's parent variable pool. When you define a class, at runtime the first time you use that class a variable pool is created to hold the class instance variables. These variables are the ones "expose"d on methods that have the CLASS attribute (a class method). There will always be one and only one of this variable pool as all instances of the class share this variable pool. When you create an instance of the class another variable pool is created to hold all the instance variables for that instance. These variables are the ones "expose"d on normal methods of the class. Each instance of the class will have its own variable pool and it cannot be shared except through a public method. ooRexx has a lot of helper short cuts (or syntactic sugar as Rick refers to it) to help you get access to the instance variable pool. When you run a method another variable pool is created to hold all the local variables used in that method. This is why you have to expose the instance variables because the default variable pool for a method is NOT the instance variable pool. The bottom line here is that in ooRexx there are a LOT of variable pools being used. Luckily there is not a lot of overhead for this so you don't see any runtime impacts. I hope this explanation helps. Oh, it took me a while to figure all this out so don't feel like you have a thick skull. At my age my skull is getting thicker every day :-) David Ashley ooRexx Team On 07/30/2010 10:07 AM, Mark Miesfeld wrote: > On Fri, Jul 30, 2010 at 6:51 AM, Anderson Goulart<[email protected]> wrote: > > >> Reading the manual, I saw that we can create object attrs using expose >> inside the method, but you actually can create them using ::attribute. Is >> that right? Any differences between them? >> > There are subtle differences. And this is an area that has always > given me trouble, so I'm not sure if my explanation will be the best. > > expose doesn't create an attribute, it creates an instance variable. > > The ::attribute directive also creates an instance variable, but it > also creates two accessor methods, in the normal usage. One to set > the instance variable and one to get the instance variable. (Although > the ::attribute directive also takes keywords that can alter this.) > > Instance variables are only visible within the instance object itself, > whereas attribute methods are / can be visible outside of the instance > object. > > These are subtle differences, to me, and took me awhile to grasp. > > >> Like these examples: >> >> /* first example */ >> ::class Example >> >> ::method init >> expose sample >> sample = 0 >> >> >> /* second example */ >> ::class Example >> >> ::attribute sample private >> >> ::method init >> self~sample = 0 >> >> >> It is not clear for me if expose lets "sample" attr become private, >> protected or public. >> > The expose is very much private, but actually even move restrictive. > Take these two examples, roughly based on what you posted. > > /* First example */ > obj = .GoodExample~new > > obj~makeValid > say "Is obj valid?" obj~isValid > > obj~makeInvalid > say "Is obj invalid?" obj~isValid > > > ::class Example public > > ::method init > expose valid > valid = .false > > ::method makeValid > expose valid > valid = .true > say "Made this object valid" > > ::method makeInvalid > expose valid > valid = .false > say "Made this object invalid" > > > ::class GoodExample subclass Example > > ::method init > self~init:super > > ::method isValid > expose valid > return valid > > When run from the command line you will see: > > C:\work\wc>qTest.rex > Made this object valid > Is obj valid? VALID > Made this object invalid > Is obj invalid? VALID > > C:\work\wc> > > That's not the output I was expecting when I first started programming > in ooRexx. > > On the other hand, this second example does work as I first expected: > > > obj = .OtherExample~new > > obj~makeValid > say "Is obj valid?" obj~isValid > > obj~makeInvalid > say "Is obj invalid?" obj~isValid > > > ::class ExampleTwo public > > ::attribute valid private > > ::method init > expose valid > valid = .false > > ::method makeValid > expose valid > valid = .true > say "Made this object valid" > > ::method makeInvalid > expose valid > valid = .false > say "Made this object invalid" > > ::class OtherExample subclass ExampleTwo > > ::method init > self~init:super > > ::method isValid > return self~valid > > The output is: > > C:\work\wc>qTest2.rex > Made this object valid > Is obj valid? 1 > Made this object invalid > Is obj invalid? 0 > > C:\work\wc> > > So, the key thing is that when you use expose to create an instance > variable, 'valid' in this case, it is only visible in the direct > instance object. > > In the first example, even though the GoodExample object is an Example > object, the 'valid' instance variable in Example is not visible in the > GoodExample object. > > Whereas in the second example, by using the ::attribute directive, you > give subclass objects a way to access the 'valid' instance variable, > even though the attribute is private. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Oorexx-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-users > > ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Oorexx-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-users
