On 27/05/17 20:30, nore...@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]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
