Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!netcomsv!jls
From: jls@netcom.COM (Jim Showalter)
Newsgroups: comp.object
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <1991Jun21.013944.23970@netcom.COM>
Date: 21 Jun 91 01:39:44 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 <KERS.91Jun20103727@cdollin.hpl.hp.com>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 56

kers@hplb.hpl.hp.com (Chris Dollin) writes:

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

That's why--in Ada at least--you can RENAME the parameter inside the body
of the procedure. This gives you the best of both worlds--a formal name
that is ideal from the client's standpoint specified in the interface,
and a second formal name that is ideal from the implementor's standpoint
specified in the hidden part of the unit.

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

It gets unacceptably ugly as the number of arguments increases above 1, which
means that in the typical case, you want named parameters:

    Print (This_Comment => "I love named parameter names",
           With_This_Spacing => 5,
           On_This_Device => Devices.Laserprinter,
           In_This_Font => Fonts.Helvetica);

and so forth. I find this considerably better than a name like
Print_Comment_With_Spacing_Device_and_Font_Toggles or some such.

>It can be too verbose to *read* as well. If it makes code unecessarily large,
>that is in and of itself a maintenance problem.

Here we go again. The C equivalent of the above would typically look
something like:

    prnt("I love named parameter names",5,lsptr,hlvtca);

This DOES take up less space. Is it more readable?

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

Indeed. This is why--in Ada at least--one can OPTIONALLY use named parameter
association, or not, depending on what is most readable in each particular
case. If you refer back to the post that originated this arm of this thread,
the poster was asking how best to approach a naming problem. In that particular
case, I argue that the best approach is to use named parameter association.
In other cases, I might well say it is overkill. But at least one should
have the OPTION.
-- 
*** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 ****
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *