RE: assignment, reference, += and parameter passing

["David Simmons" <address@hidden>]

This is what we (in designing QKS Smalltalk), termed a "destructive"
operation. The general problem is the result of allowing assignment into
a language.

The solution is not necessarily simple, and may largely depend on
intrinsic language facilities and the corresponding development
environments for the language(s).

In Smalltalk, by standard framework convention, almost every
operation/message defaults to a copy-and-modify unless there is some
explicit getter/setter or "put:" involved. 

So if you write:

   |pt| := 0@0. "a point"

Then you write:

    pt + (1@0).

The point object referred to by the <pt> variable is not modified. It is
copied, and the copy is then modified and returned. This can be very
inefficient. So some sometimes one wants to explicitly declare/write a
method that does "destructively" modify the message receiver (or one of
its arguments). 

Typically such methods [if they are not following a getter/setter
pattern which implicitly is destructive] are annotated with a tag,
category, and/or documentation to make the "destructive" nature clear.
These methods may also be categorized as infrequent/special/uncommon
methods. Which in turn affects how they are presented to a developer
within an IDE/browser system.

-- Dave S. [SmallScript LLC]

SmallScript for the AOS & .NET Platforms
David.Simmons@SmallScript.com | http://www.smallscript.org


> -----Original Message-----
> From: owner-ll1-discuss@ai.mit.edu
[mailto:owner-ll1-discuss@ai.mit.edu]
> On Behalf Of Paul Prescod
> Sent: Wednesday, December 19, 2001 8:35 AM
> To: ll1-discuss@ai.mit.edu
> Subject: Re: assignment, reference, += and parameter passing
> 
> David Simmons wrote:
> >
> > The semantics of "+=" don't have this possible ambiguity in
Smalltalk
> > because "+=" is not a special operator. I.e., everything is a
message
> > and any message can be defined/redefined at any time by an
implementor
> 
> Right. That's how it behaves in Python also. The problem is that the
> built-in objects do not have consistent definitions for their
behaviour
> on receiving the "+= message". Some people want += to be a mutating
> operator. But when it can't mutate the object (e.g. an integer),
people
> still want to be able to use it, so those classes define it such that
it
> creates a new object.
> 
>  Paul Prescod