>> The only distinction with strings is that they are "immutable". I thought that was the case. Btw, I can't find a statement to this effect in either the ooRexx Reference or Programming Guide.
Oliver -----Original Message----- From: Rick McGuire [mailto:object.r...@gmail.com] Sent: 10 January 2012 22:24 To: Open Object Rexx Developer Mailing List Subject: Re: [Oorexx-devel] ooDialog - inout param inmethod'mapWindowPoints'? On Tue, Jan 10, 2012 at 5:17 PM, Oliver Sims <oliver.s...@simsassociates.co.uk> wrote: > Jon, > > Many thanks - I'm afraid I must have suffered (a hopefully temporary) > brain failure. Your explanation is crystal clear. Of course - a method > param (as you say) is an object, so it's (almost) always a > pass-by-reference. I say "almost" because strings and stem vars are > objects but are (or at elast seem to be) pass-by-value. Actually, no. All arguments are just references to objects. The only distinction with strings is that they are "immutable". There are no methods that can be used to change the internal state of a string object, so there is no way to produce this sort of effect with strings. Stems actually can have their internal state changed. Rick > > Thanks again, > Oliver > > > ________________________________ > From: Sahananda (Jon) Wolfers [mailto:sahana...@windhorse.biz] > Sent: 10 January 2012 18:19 > > To: Open Object Rexx Developer Mailing List > Subject: Re: [Oorexx-devel] ooDialog - inout param > inmethod'mapWindowPoints'? > > Hi Oliver, > > pardon me if I'm telling you something you already know. > > It is probably not helpful to think of this as an inout parameter. > > What is happening is that p in your example or r in Marks refers to an > object-instance. That object-instance has a life from the time that > it is instantiated until, no longer needed it is cleared away by the > garbage collection. > > When you pass the object-instance to another object or method or > routine, which uses USE ARG to receive it, you are passing a > reference, not a value (which is what gets passed with PARSE ARG). So > now, you have a variable within the called routine which points to the > object-instance, but the variable in the caller routine still points > to it too. They both point to the self-same object-instance. > > The called routine could pass control back with a reply statement, and > then you would have a concurrency situation, where both bits of code > could simultaneously send messages to the same object instance. > > As it happens, in this case, there is no concurrency, so the calling > code sits and waits until the called code is finished, and then carries on. > > I hope that that serves to clarify rather than confuse. > > Jon > > On 10 January 2012 17:40, Oliver Sims > <oliver.s...@simsassociates.co.uk> > wrote: >> >> Mark, >> You said (and I had to laugh): According to who is the "usual" way? >> Then I thought, well, I can't think of any existing function or >> method in ooRexx where the returned value is to be found in a method >> parameter. But that may well indicate my incomplete knowledge of >> ooRexx - if so, please do let me know where inout params are used. I >> guess I've always thought that, with ooRexx, if you want to >> distinguish between a returned value and a return code, you have to >> arrange to return two things - which you can't - so then you cheat >> and return say a directory with two entries. Acutally having an inout >> parameter makes sense for that situation - which is exactly the situation for the MapWindowPoints (and presumably some other ooDialog APIs). >> >> For the Guide, if there are no examples of inout params in ooRex as >> shipped, I'll need to describe inouts as an ooDialog feature to >> handle situations where one needs to distinguish between values >> returned and return codes - which happens of course when one is >> hiding the programmer from an underlying piece of middleware that you can't change. >> >> Atb, >> Oliver >> >> ________________________________ >> From: Mark Miesfeld [mailto:miesf...@gmail.com] >> Sent: 10 January 2012 14:59 >> To: Open Object Rexx Developer Mailing List >> Subject: Re: [Oorexx-devel] ooDialog - inout param in >> method'mapWindowPoints'? >> >> On Tue, Jan 10, 2012 at 5:48 AM, Oliver Sims >> <oliver.s...@simsassociates.co.uk> wrote: >>> >>> In Mark's userDlg.rex drag-drop sample program, there's a method >>> "mapWindowPoints". >>> The code is: >>> >>> say 'Mouse position before map:' p >>> self~mapWindowPoints(self~DlgB~hwnd, p) say 'p after map:' p >>> >>> The parameter p is changed by the method implementation. >>> >>> The parameter 'p' is what Corba IDL calls an "inout" parameter - it >>> serves to provide data to the method and the method also uses it to >>> return data to the caller. This is the first time I've seen this in >>> Object Rexx. So I wondered if it's intended to keep this behavior, >>> or to change it so that it returns data in the usual way? >>> >> >> >> It's intended to be this way. "returns data in the usual way" seems >> a little bit of a questionable statement to me. According to who is >> the "usual" way? <grin> >> >> This type of method, transforming some object, is common in the new >> methods I've introduced in ooDialog. >> >> In places where it is used, and mapWindowPoints() is a good example, >> the existing values of the object are not needed, it is the >> transformed values that are needed. There is no need to have 2 >> separate objects. In addition, it allows the method to return a >> success indicator for methods where the data returned does not have >> an obvious failure value. In this case it returns false on failure. >> >> -- >> Mark Miesfeld >> >> >> --------------------------------------------------------------------- >> --------- >> Write once. Port to many. >> Get the SDK and tools to simplify cross-platform app development. >> Create new or port existing apps to sell to consumers worldwide. >> Explore the Intel AppUpSM program developer opportunity. >> appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > > ---------------------------------------------------------------------- > -------- > Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. > Create new or port existing apps to sell to consumers worldwide. > Explore the Intel AppUpSM program developer opportunity. > appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ---------------------------------------------------------------------------- -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
