Re: Reference vs. copy semantics in passing parameters

[sommar@enea.se (Erland Sommarskog)]

Also sprach Micheal Feldman (mfeldman@seas.gwu.edu):
>Jim Showalter (jls@yoda.Rational.COM) writes:
>>In C++, you can declare not only the pointer constant but the pointed
>>to construct constant as well. This allows passing by reference in a
>>read-only manner, which is NOT possible in Ada at present.
>
>Well now I'm curious. Given that only scalars and small structures are
>usually passed by copy, why would you want to guarantee reference
>passing for read-only parameters in such a kludgy way? Ada provides you
>with everything you need:

Don't get confused by terminology. Forget about passing mechanisms.
Remember data abstraction.

If you have a routine which takes a pointer parameter as IN, you
are guaranteed that the *pointer* don't change, but the object
pointed to may be completely altered. For instance look at:

   PROCEDURE P(X : IN ADT);

Am I as a caller that Do_something from this signature guaranteed
that P does not change X? Answer: No. If I look in the package
specification I find that ADT is limited private. Only if I cheat
and sneak into the private part and find that ADT is declared as
a pointer-less type I know that X won't change. If there is a pointer,
and often that's all an ADT is, P may change X just as much as it
wants. Remember that as a user, I may perceive X as a completely
static object.

The practical implication is on the side of the ADT implementor. He
may choose to define ADT as a pointer in order to be able to defer
the record definition to the package body, and thereby reducing
recompilation impact in case he adds or removes a field. The cost
of this is that he loses compiler control of inadvertent changes
to IN parameters, and we're back on the Pascal level.

>PS: It seems to me that Ada9x could clarify the issue by simply requiring
>that structured parameters be passed by reference (instead of the Ada83
>rule that it's implementation-dependent). Since a program whose behavior
>depends upon the method of passing is - by definition of the LRM -
>erroneous, the only programs that would break would be erroneous ones,
>which Ada9x says it doesn't care about. So the clarification would be
>upward compatible. Ada9x-ers: what would be the objections?

Ada should not bind the implementors in order to make ugly
programming unambiguous. Rather I think Ada is going too far
when requiring a certain implementation in some situations.
The IN, OUT and IN OUT modes are a beautiful invention with
exception of the problems mentioned above.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
"...I cannot understand someone saying 'Rush makes pretty good music, 
but they ARE commercial'." -- William J Bouma