Re: [Oorexx-devel] ooDialog - inout param inmethod'mapWindowPoints'?
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. 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 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 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? 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
Re: [Oorexx-devel] ooDialog - inout param inmethod'mapWindowPoints'?
On Tue, Jan 10, 2012 at 5:17 PM, Oliver Sims 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 > 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 >> 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
Re: [Oorexx-devel] ooDialog - inout param inmethod'mapWindowPoints'?
>> 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 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 > > 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 >> 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~mapWindow
Re: [Oorexx-devel] ooDialog - inout param inmethod'mapWindowPoints'?
Yes, good point. I think you have to infer it from section 5.4.14 The MutableBuffer class is a buffer on which certain string operations such > as concatenation can be performed very efficiently. Unlike String objects, > MutableBuffers can be altered without requiring a new object allocation. A > MutableBuffer object can provide better performance for algorithms that > involve frequent concatenations to build up longer string objects because > it creates fewer intermediate objects. Jon On 10 January 2012 23:06, Oliver Sims wrote: > >> 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 > 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 > > > > 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 > >&g
