Path: utzoo!attcan!uunet!microsoft!paulc
From: paulc@microsoft.UUCP (Paul Canniff 2/1011)
Newsgroups: comp.lang.c++
Subject: Re: Named arguments?
Message-ID: <7460@microsoft.UUCP>
Date: 21 Aug 89 01:34:56 GMT
References: <612@windy.dsir.govt.nz> <2179@uw-entropy.ms.washington.edu> <30765@lll-winken.LLNL.GOV> <13186@well.UUCP>
Reply-To: paulc@microsoft.UUCP (Paul Canniff 2/1011)
Organization: Microsoft Corp., Redmond WA
Lines: 35

In article <13186@well.UUCP> nagle@well.UUCP (John Nagle) writes:
> 
>      When a large number of optional, positional arguments are allowed,
> the call can get a bit painful.
> 
> 	z = plot(x,y,,,,,,1,,,'c');
> 
> is not something one finds desirable.  This sort of thing is a curse of
> some mainframe job control languages.  We don't want to bring it back.

It is, however, a simple and logical extension of the current
"optional arguments" in C++.  IMHO it is no more offensive than
the current stuff;  and if you have that many args, you have a problem
anyway -- the methods and objects are becoming too complex, and it's
time to look for component objects and methods which can be combined
to satisfy the requirement.

>      One major advantage of named, optional arguments, is that when it
> becomes necessary to add a new feature to a package, or to delete an
> unused one, all the callers of the package need not be revised.  Whatever
> solution is chosen should definitely retain this property.

Revised, no.  Recompiled, probably.  I am assuming that to retain
efficiency, the translation from a named unordered list to an unnamed
fixed list is done by the compiler, and not at runtime.  So adding
options may or may not require recompilation.

Using methods to define the state of an object seems to
provide even more flexibility that named arguments, because it allows
the object to be extended w/o revising OR RECOMPILING the original
source.  And in the world of distributing processing, where
messages to objects may actually be shipped across a network, it is
very desireable to have the new object be compatible with the
methods of the old object;  it's hard to guarantee that everyone will
be running the same version!