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

[Richard Riehle <richard@adaworks.com>]

Hyman Rosen wrote:

> 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"?

In fact, I do care about this.    The performance characteristics
of each kind of sort are important.    Under some circumstances
I want to use a Merge Sort utility and other times I want a
Quicksort.   This is one place where I can benefit from a knowledge
of the Big O notation.

> 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?

I will want to have information in the contract that gives the client of
my specification an opportunity to choose which method to invoke,
and what to expect from it.   It might be quite useful for a client to
know that a method is managed or not managed, but this does not
have to be part of the name.    In my example, I included preconditions
and postconditions in the form of meaningful exception names.   These also
provide some information for the client.

In the legal world, there is something called "due notice."   Any contract,
including a type/class specfication, needs to be explicit.

> 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.

Actually, when considering the need for clarity, I think there is a difference.

The technique for preventing assignment in C++ is not, in my mind, as
clear as the declaration of a limited type.   The fact that some construct
can be expressed in a particular language does not mean it is best
expressed in that language.   We will simply have to agree to disagree
on the point regarding limited types.

Richard Riehle