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:[email protected]]
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 <[email protected]>
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:[email protected]]
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
<[email protected]> 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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
