Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!att!lzaz!bds
From: bds@lzaz.ATT.COM (B.SZABLAK)
Newsgroups: comp.lang.c++
Subject: Re: MI and namespaces
Summary: Not a new problem
Keywords: MI namespaces
Message-ID: <592@lzaz.ATT.COM>
Date: 24 May 89 12:47:31 GMT
References: <192@mole-end.UUCP> <11541@ulysses.homer.nj.att.com> <195@mole-end.UUCP>
Organization: AT&T ISL Lincroft NJ USA
Lines: 17

In article <195@mole-end.UUCP>, mat@mole-end.UUCP (Mark A Terribile) writes:
> ... If XYZ company
> releases an improved version of their ZeeYooXee class and library, they
> can create an ambiguity in my code.  The inability to say ``you can get the
> name, but we won't press it on you,'' leaves no ``out'' for the designer of a
> class who has to get everything right for all time.

I think XYZ company has the responsibility for insuring that the interface to
the abstract data type they provide does not change from release to release.
I don't think this is unreasonable since I also expect the declarations to
"standard" C functions to remain the same with each version of libc.a. Do you
lose sleep at night worrying that open() will require something other than a
file name as its first argument?

Naturally, this puts a great deal of pressure on XYZ company to get it right
the first time, or (more likely) to support there first offering even as they
proceed to future ones.