Curt Sampson wrote:
> Actually, you need pass by reference for arguments where you want the
> function to have side-effects affecting that argument.

That's my point. I'm not sure we do NEED them. Side-effects are exactly
the couse of concern which leads to more bugs and thus unreliable
software.

> I think a much better way of getting the kind of "reliability" you're
> talking about is to always pass by reference, but wherever you can,
use
> value objects. Methods that would "modify" a non-value object instead
> return a new value object with the modified state. For example,
>
>      p1 = Point.new(17, 35);
>      p2 = p1;
>      p1 = p1.move(0, 5);
>
> Now p2 still refers to the point (17,35), but p1 has been changed to
> refer to a different point (17, 40) (rather than the point itself
> changing). This helps greatly to avoid aliasing.

Hm... but doesn;t that still leave it all up to the programmer? And it
is terribly inefficient.

> Avoiding side-effects as much as possible in this way is OO in sort
of a
> functional programming spirit.

Right. And I ownder if it isn;t worth enforcing --and finding
intelligent ways to to id it efficiently.

> One of the things I think Java did right was to make Strings
immutable.
> One of the things I think Java did wrong was to make Dates mutable.

Maybe so for the dates.

But I'm hinting at transcending this in a way with regards to argument
passing. Arguments would become as if immutable (and side effect must
enforce a duplication) unless it was seen that the passed object was
returning on output from the same place it came from on input. Does
that make sense?

T.