Method to decide whether to return copy, or modify receiver

[ErichSt]

Can a method find out whether it is expected to return a (modified) copy of the receiver, or if it should directly modify the receiver?

I'd like to code e. g. a method "transpose" that, when called with

"Trans=Matrix~transpose"
it would return a copy of the transposed matrix, but when called with

"Matrix~transpose" (or, when called through the "~~" syntax)
it would directly modify "Matrix" by transposing it

[Glenn Knickerbocker]

On Sun, 7 Apr 2013 07:31:15 -0700 (PDT), ErichSt wrote:
>Can a method find out whether it is expected to return a (modified) copy
>of the receiver, or if it should directly modify the receiver?

Nope. Instead, you can make it always modify the receiver, and make your
copy *before* calling it:

Trans = Matrix~copy~~transpose

(I might also make it return the receiver, so I didn't have to worry
about remembering to use "~~".)

With routines, the distinction between function and subroutine tells the
routine whether the caller will use the result in an expression, and you
can use that to control the behavior, but I think it was originally
mostly just a matter of convenience in preventing unwanted side effects:

routine(argument) /* issues the result as a host command */
call routine argument /* doesn't */

With methods, instead the language processor just ignores the result if
it's not in an expression:

object~method /* does nothing */
(object~method) /* issues the string value as a host command */

So the caller didn't need a way to tell the method whether the result
would be used.

An interesting idea I had in thinking about this was something analogous
to the special handling of "=" at the end of method names:

object~method = argument /* calls method 'method=' if it exists */

especially as used together with the special treatment of '[]' and
parsing of expressions:

collection[index] = item /* method '[]=' sets the item */
Say collection[index] = item /* method '[]' returns the item */

If there were similar treatment of "=" before the object name:

variable = object~method /* call method '=method' if it exists */

then you could use that to trigger the copy:

::method '=transpose'
forward to (self~copy) message ('transpose')

We'd have to worry about collisions:

object1~method1 = object2~method2 /* What should happen
if object1 has both 'method1' and 'method1=' methods,
*and* object2 has both 'method2' and '=method2' methods?
*/

But really it's too late to add such a thing compatibly anyway, since
programs could already be using methods with names matching this or any
other convention we chose.

�R / Darla: Leftovers aren't the mark of a man. \ www.bestweb.net/~notr
Andrew Reid: Actually, they are, because that's how men's shirts button.

[Glenn Knickerbocker]

On Sun, 07 Apr 2013 15:25:55 -0400, I wrote:
>We'd have to worry about collisions:
>
> object1~method1 = object2~method2 /* What should happen
> if object1 has both 'method1' and 'method1=' methods,
> *and* object2 has both 'method2' and '=method2' methods?
> */

Thinking a second more about collections, I guess you'd want to apply the
rule on both sides:

collection[index] = Matrix~transpose /* call '[]=' and '=transpose' */

But this idea doesn't help any in the case where you want to use the
result in an expression rather than a direct assignment

Pair = .array~of(Matrix, Matrix~copy~~transpose)

Even with a new rule allowing a message term starting in '=' to begin an
expression, you'd still have to use a special form:

Pair = .array~of(Matrix, =Matrix~transpose)

�R "I love Blip just because it's the absolute opposite of fun"
http://users.bestweb.net/~notr/travelog/19990710.html --Kibo

[ErichSt]

Glenn, thanks for your answers.

I for sure would love to have whatever means to distinguish between those cases.

[Glenn Knickerbocker]

On 4/8/2013 3:21 AM, ErichSt wrote:
> I for sure would love to have whatever means to distinguish between those cases.

In the absence of a syntax construct like 'method=', you can still use
the same principle, just with a different naming convention:

::method transposed
return self~copy~~transpose

I think that would make the distinction pretty self-evident to anybody
using it: "transpose the matrix" vs. "the transposed matrix."

ŹR