Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!oliveb!Ozona!chase From: chase@Ozona.orc.olivetti.com (David Chase) Newsgroups: comp.lang.c++ Subject: Re: Default argument values Message-ID: <45449@oliveb.olivetti.com> Date: 25 Jul 89 20:31:28 GMT References: <43253@bbn.COM> <20077@paris.ics.uci.edu> Sender: news@oliveb.olivetti.com Reply-To: chase@Ozona.UUCP (David Chase) Distribution: comp Organization: Olivetti Research Center, Menlo Park, CA Lines: 56 In article <20077@paris.ics.uci.edu> schmidt@glacier.ics.uci.edu (Doug Schmidt) writes: >There's also another problem. Allowing ``named parameters,'' a la >Ada, weakens information hiding, since formal parameter names are now >visible *outside* their original scope! > >On the other hand, in a language that allows named parameters you need >to hunt down all instances of the formal parameter names occurring in >all *calls* to the function. These calls are potentially spread >throughout many source files, and it becomes difficult to change the >names in an automated fashion, for the reasons alluded to above. > >IMHO, named parameters are another Ada (mis)feature that adds >gratuitous complexity to the compiler and programmer without providing >much value-added benefit. Don't knock them until you've tried them (and compiled them). Keyword and default parameters are in Mesa and in Modula-3 (among others), and they work just fine. If you have a language with separate interfaces and implementations, the "exposes formal parameter names" argument is bogus. From the point of view of the called procedure, the only important thing is the parameter position and the parameter type (yes, it is correct that the compiler fills in the parameters at call sites if they aren't supplied). Thus, the names in the interface and the names in the implementation need not correspond to each other (though I'm not sure what Ada, Modula-3, and Mesa do about this), so nothing has been revealed about the implementation. That is, there's two scopes, not one, and the conditions on signature matching say nothing about the names of the parameters. This is a curious sort of "information hiding"; I thought one was supposed to hide the internals of a module, not its interface. Choice of parameter names has plenty to do with the interface, and very little to do with the implementation. Generally (anyhow), interfaces are expected to be somewhat unchanging, and signatures of procedures are certainly expected to be somewhat unchanging. Even so, if you did find it necessary to change a procedure signature, you may rest assured that the compiler will inform you of any calls which do not conform to the standard. If you fail to recompile a module, then the pre-linker will inform you of this (since generation of makefiles and dependency checking is automated, this should not happen, anyway). (The above may sound like some weird fairy-tale, but it's all in place, and it all works well for Modula-3. I don't know enough about C++ to think of any reasons why it shouldn't be possible for C++.) How does this differ from the exchange of two parameters in a list, anyway? You'd need to hunt *those* down, and (if they were of the same type) the compiler and linker wouldn't tell you anything. This doesn't look like a win to me. Keyword parameters take care of *that* automatically. David