mat@mole-end.UUCP (Mark A Terribile) (05/18/89)
Does anyone else have a feeling of possible impending doom lying around the corner somewhere near MI? Let's say that one of my various base classes (Ba) has a void Ba::reverse() . I also have a base class Bb, and one day into one of *its* base classes (Bbb, let us say) I add a base class which as a Bbb_b::reverse() . I have now created an ambiguity. It's not clear to me that I can solve anything by making one of the base classes private, and I don't really want to do that anyway. All I want to do is prevent Bb_b::member_xyz from being IMPLICILTY visible and from being able to cause an ambiguity. In other words, I want Bb_b::member_xyz to be visible in my ``most derived'' class as Bb_b::member_xyz but *not* simply as member_xyz . Moreover, I may have another member_xyz which I *do* want to be able to refer to without qualification. Making the base class private and making public only the members you mean to use may or may not solve the problem, depending on whether invisible private members can create an ambiguity with visible ones. (I've heard it both ways, most recently that they can. Will some very knowledgable person please straighten me out?) I fear that inheriting from lots and lots of base classes to get a variety of capabilities is almost sure to lead, sooner or later, to enough ``print''s and ``dump''s and ``debug''s and ``verify''s that we are either going to begin prefixing these names with the class qualifer out of habit or we are going to prepend the class's name to the member name we would like to use. This will indicate (to me at least) that the name space controls we have are inadequate. (This fear was reinforced today by my superior, who described the chaos that occurs when namespaces are merged without controls as ``unstructured global goto's.'' I share this bogey with someone, at least.) -- (This man's opinions are his own.) From mole-end Mark Terribile
jss@hector.UUCP (Jerry Schwarz) (05/18/89)
In article <192@mole-end.UUCP> mat@mole-end.UUCP (Mark A Terribile) writes: > >Making the base class private and making public only the members you mean to >use may or may not solve the problem, depending on whether invisible private >members can create an ambiguity with visible ones. (I've heard it both ways, >most recently that they can. Will some very knowledgable person please >straighten me out?) > The basic principle in C++ visibility control is that the use of "public", "protected", and "private" do not change the meaning of a program, they only affect its legality. This principle has some drawbacks, in particular it means that the presense of private members somewhere in an inheritance hierarchy may create a conflict with public ones. It has the advantage that it is simple to state and understand. >I fear that inheriting from lots and lots of base classes to get a variety of >capabilities is almost sure to lead, sooner or later, to enough ``print''s and >``dump''s and ``debug''s and ``verify''s that we are either going to begin >prefixing these names with the class qualifer out of habit or we are going to >prepend the class's name to the member name we would like to use. I suggest that when you derive a class D from multiple base classes that both have a "print", or "dump", you have a real ambiguity and the programmer must resolve it by supplying a "D::print" a "D::dump", etc. > This will >indicate (to me at least) that the name space controls we have are inadequate. I agree that MI makes it more delicate to add members to base classes. There has always been the potential for problems when you do this, but they are more likely to arise in the presense of MI. Jerry Schwarz AT&T Bell Labs, Murray Hill
mat@mole-end.UUCP (Mark A Terribile) (05/20/89)
> >I fear that inheriting from lots and lots of base classes ... is almost sure > >to lead, sooner or later, to enough ``print''s and ``dump''s ... that we > >are either going to begin prefixing these names with the class qualifer out > >of habit or we are going to prepend the class's name to the member name > >we would like to use. > I suggest that when you derive a class D from multiple base classes > that both have a "print", or "dump", you have a real ambiguity and > the programmer must resolve it by supplying a "D::print" a "D::dump", > etc. ... [I think] that the name space controls we have are inadequate. It does, however, create problems for maintainance and enhancement. 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 agree that MI makes it more delicate to add members to base > classes. There has always been the potential for problems when you > do this, but they are more likely to arise in the presense of MI. It makes it much harder or more dangerous to use MI freely in large, real-world projects. C++ is the only thing that can support MI (or something like it) with reasonable efficiency. Having people ``protect'' all their (potentially) virtual function calls with class quailfiers to safeguard the next generation of developers seems to me to impair the usefulness of the semantics. I realize that, as with everything else, it's easier to botch language changes of this sort than to get them right. I also don't expect to hit this problem for a few years. I would like, though, to believe that someone is thinking about the problem. -- (This man's opinions are his own.) From mole-end Mark Terribile
bds@lzaz.ATT.COM (B.SZABLAK) (05/24/89)
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.