Re: True faiths ( was Re: The true faith )

[Hyman Rosen <hyrosen@mail.com>]

Richard Riehle wrote:

> Hyman Rosen wrote:
>>Richard Riehle wrote:
>>>        procedure Copy_Deep       (Source : in T; Target : in out T);
>>>        procedure Copy_Shallow  (Source : in T; Target : in out T);
>>>
>>I dislike the notion of providing these methods as external interfaces
>>to a type. It seems wrong to me for a client to have to know what kind
>>of copy to use - that's the type's business to know.
> 
> Well I don't like having an assignment statement that behaves in an
> unpredictable way when I use it.


I think we can agree on this with unbridled enthusiasm :-)

> So I prefer having the copy semantics spelled out as clearly as possible.

 > This clarity assures me that, when I call a method, it will behave as
 > I expected.

But the user of a type generally isn't concerned with its innards.
Why would you take a simple concept like copying or assignment and
burden it with implementation details? If you were writing a sort
method for a conatiner, wouldn't you just call it "sort" rather than
"merge_sort' or "bubble_sort"?

And if we were to say "do as Ada does", consider Unbounded_String.

> As to the client needing to know which copy to use,  in practice we
> would make only one available, but we would make clear the semantics
> of that copy.   The other point is that using Ada's limited types, we
> don't have to worry about making mistakes regarding the assignment
> operation.


Well, the normal semantics of a copy are that the source and destination
are not tied to each other after the copy is made. Of course, internally
that might not be true, because you could be maintaining reference
counts, and doing copy-on-write. You would place all that information
into the routine name?

And limited types are irrelevant here. C++ and Ada can both prevent
assignment from compiling. The problem was writing assignment correctly
when you do want to provide it.