Static Polymorphism (Was Re: Naming of Tagged Types...)

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Thu, 30 Jul 1998, Matthew Heaney wrote:
... snip ...
> Because I want a client to be able to easily change the code if he
> changes his mind about what kind of stack he needs (say, to go from a
> bounded stack to a dynamic stack with a statically allocated heap), I
> just named all the stack types Stack_Type.  (Brian Rogoff must be
> smiling right now...)   Just like File_Type.
> 
> This does not mean, however, that you should name every type using the
> _Type convention.  This is a big mistake, because then the convention
> would loose its value as an indicator of static polymorphism.
> 
> For example, the active iterator for the Stack_Type is called
> Stack_Iterator.  It's not just any Iterator_Type, it's an iterator for
> stacks, so call it that.

I wonder why you would want to name the iterator type Stack_Iterator,
since it seems to defeat the goals you describe for minimal rewriting
when changing implementation?
 
For example, if you wanted to replace the stack with a deque, or a singly 
linked list, you have to rename all occurrences of Stack_Iterator. If you 
take a look at the collection library at http://www.best.com/~bpr/agl.html 
which is also "tagged-type-free", you'll see that I copied from the C++
STL, and named the iterators based on the kinds of iteration they support,
Unidirectional, Bidirectional, Random_Access, etc., rather than on the
data structures they iterate over. This gives you what you are calling 
"static polymorphism", and allows you to write many algorithms in terms 
of iterators alone.

If you can tolerate reading C++, check out the STL, you'll find that you 
share some design goals with its authors.

-- Brian

PS: The sorting routines in my library right now weren't meant to work; I
just forgot to yank them out. I'll put real working versions on the net 
soon, after I figure out whether I want a Swap_Values routine in the
iterator signatures...