Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.object Subject: Re: Re: Functions without side effects (was Old confusion) Message-ID: Date: 20 Jun 91 09:37:27 GMT References: <130242@tut.cis.ohio-state.edu> <4888@osc.COM> <72893@microsoft.UUCP> <4116@ssc-bee.ssc-vax.UUCP> <4907@osc.COM> <1991Jun19.173 Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 62 In-Reply-To: jls@netcom.COM's message of 19 Jun 91 17:31:44 GMT Nntp-Posting-Host: cdollin.hpl.hp.com Jim Showalter [indented below] extolls the virtues of keyword parameters. in--yes, I realize other languages have this capability), you could write things like: procedure Print (This_Many_Lines : in Integer); The formal name "This_Many_Lines" eliminates any confusion about what the Integer argument might specify. For languages that have this capability, there is a nice additional feature that makes a natural companion to formal parameter names--named parameter association. In Ada, you could call the above procedure like this: Print (This_Many_Lines => 8); I think it's a mistake to tie in the name of the formal parameter to the interface of the procedure; the calling keyword has a right to be verbose, but the *parameter* name may be used repeatedly in the procedure, and has the right to be short. ("You have the right to remain ....") Note how this makes the code inherently self-documenting, always a noble goal. Contrast this with: Print (8); Which is the only argument binding syntax available in less readable languages--from the above the reader cannot deduce whether the Print is going to print the numeral 8, or eight of something, or what. I'd choose a different name for the procedure: this ensures that the keyword-syntax cannot be accidently left out (not being there). Of course this gets harder as the number of arguments increases. Now, I get complaints occasionally that the version using named parameter association is too verbose. I've noticed that such complaints typically come from hunt-and-peck typists with little or no background in maintenance, which pretty much says it all... It can be too verbose to *read* as well. If it makes code unnecessarily large, that is in and of itself a maintenance problem. (Doesn't a respectable maintenance environment allow you to see the call annotated with the meanings of the parameters anyway?) Keyword-calling is less useful in languages making free use of procedure-valued variables (ie higher-order functions). If you have keyword-constructors for record aggregates (eg, rectype( fieldX as exprX, fieldY as exprY )) then some uses of keyword arguments can be replaced by calls with suitably constructed aggregates. -- Regards, Chris ``GC's should take less than 0.1 second'' Dollin.