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 <[email protected]>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:[email protected]]
> 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
> <[email protected]> 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:[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
> >
>
>
> ----------------------------------------------------------------------------
> --
> 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
>
------------------------------------------------------------------------------
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
