Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!ctrsol!ginosko!eyebeam!jbw
From: jbw@eyebeam.UUCP (Jeremy B. Wohlblatt)
Newsgroups: comp.lang.c++
Subject: Re: Default argument values
Message-ID: <2285@ginosko.samsung.com>
Date: 25 Jul 89 20:37:43 GMT
References: <FOX.89Jul23151217@cs.cs.columbia.edu> <43253@bbn.COM> <20077@paris.ics.uci.edu>
Sender: news@ginosko.samsung.com
Distribution: comp
Lines: 84

schmidt@glacier.ics.uci.edu (Doug Schmidt) writes:
>In article <43253@bbn.COM>, lpringle@bbn (Lewis G. Pringle) writes:
>>In article <FOX.89Jul23151217@cs.cs.columbia.edu> fox@cs.cs.columbia.edu (David Fox) writes:
[talk about named parameters]

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

from a software engineering point of view, i see no problem here.  the
keyword names need only be visible in the function call, which is the
interface between the calling routine and the function itself.  why
shouldn't some aspects of both be visible there?

already, the calling routine must know the order and types of the arguments (to say
nothing of the semantics), so why not provide a name if it helps the caller
write the call more clearly?  e.g., in a language which gives you defaults
and named paramenter, you might want to use an 8-parameter function but with
all defaults except one.  you could write this simply as

	load_file(infile <- foo);

rather than copying all the defaults or writing something like

	load_file(,,,, foo,,,);

basically this frees you from having to know the order of arguments
at the expense of requiring you to know the names of the ones you're
interested in.  this may make the call more clear.

consider

	copy (x, y);

versus

	copy (from <- y, to <- x);

note that i did not use the traditional `=' for parameter assignment.
it seems too hard to read and understand function calls when ordinary
assignment and parameter assignment use the same syntax, e.g.

	{
		int y;
		...
		foo (x = 3); // keyword assignment
		foo (y = 3); // local variable assignment
	}

>For example, consider the effect of changing a formal parameter name
>in C or C++.  All you need to modify are the uses of this formal
>parameter name *inside* the enclosing function.  This change is
>trivial to perform using an interactive query-replace editor feature.

but this is a problem with editors, not the software engineering structure
of the program.  the solution is better multi-file editors.  moreover,
if you change the *order* of the arguments, you've got the same problem
anyway, right?  it's reasonable to visit all the function calls whenever
you change the interface to the function.

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

on the other hand, you can change the order of the arguments and *not*
have to visit all the calls if they always used the keyword names!

>IMHO, named parameters are another Ada (mis)feature that adds
>gratuitous complexity to the compiler and programmer without providing
>much value-added benefit.

i may agree with you that this isn't a tremendously exciting feature,
but not for the reasons you cite.  personally, though, it seems to me
that if the language has a clear syntax associated with named parameters
(like the `<-' i suggested above) then there's little room for ambiguity.
nor should the compiler be all that more complex.

					-- jeremy
these opinions might not be those of my employer.  they might not even be mine.
jeremy b. wohlblatt: samsung software america, inc.
	uucp: {decvax!{gsg,cg-atla},uunet,ulowell}!ginosko!jbw
	internet:	jbw@ginosko.samsung.com