[fpc-pascal] named parameter

Mark Morgan Lloyd markMLl.fpc-pascal at telemetry.co.uk
Sun May 28 12:22:11 CEST 2017


On 27/05/17 20:30, noreply at z505.com wrote:

> IMO though it does improve readability in long functions with lots of
> parameters, like windows api style procedures that have 5 or more
> parameters and you can't figure out which param is
> which

I had an interesting case a couple of years ago where a procedure called 
itself recursively, but with a couple of the parameters shifted in 
relative position. Messing that up when I added an extra parameter 
caused a difficult-to find bug, so I think that some sort of 
identify-by-name arrangment (I'm not saying pass-by-name because of its 
historical meaning) would be useful.

procedure SendMechCodeToLineASCII(mc: word; bcd, apl: boolean; crlf: 
boolean= false;
                         lf: boolean= false; echo: boolean= false; 
loopback: boolean= false);

..

(* CR expansion, local echo etc. Note recursive echo of LF if CR is 
expanded,   *)
(* this is to keep the VM/CMS "Sixpack" happy since otherwise the first 
line of *)
(* output always tries to overwrite the command that instigated it (but 
with    *)
(* bits of the command showing through non-destructive spaces). 
        *)
(* 
        *)
(* Note intentional shift of parameter positions in the recursive call 
below.   *)

     if (mc = Op_CarrierReturn) and crlf then
       SendMechCodeToLineASCII(Op_Index, bcd, apl, {crlf :=} loopback, 
{lf :=} false,
                                         {echo := } true, {loopback :=} 
false);
     if echo then
       PseudoEventQueue.Enqueue($80000000 + canonical(mc))
   end
end { SendMechCodeToLineASCII } ;

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]



More information about the fpc-pascal mailing list