On 2019-09-16 03:21, DougC wrote:
In my view that's exactly what a procedure is for: Accept some
parameters, do some processing, store some data elsewhere, return some
results via parameters.
Functions, on the other hand, should be more limited. Accept some
data, perform one function, return one result, having no side effects.
Other languages like everything to be functions which is where the
predilection toward them comes from. The worst form of this is
functions that have side effects, return one result, but then also
return additional results via parameters. Arrgghh!
The most common use case for this function would be checking the call
result and doing something based on this result. From this point of view
it's much more logical to make it a function than requiring another
temporary variable as the parameter and performing the decision based on
value returned in this parameter, especially if the return value is
boolean.
Tomas
---- On Sun, 15 Sep 2019 18:59:51 -0400 Tomas Hajny
<mailto:xhaj...@hajny.biz> wrote ----
On 2019-09-16 00:29, DougC wrote:
But to fully correct the situation, I would also change it to a
procedure since leaving it as a function still suggests it only
returns a result and has no other side effects.
No, changing it to a procedure would not work - the information whether
BOM was found and thus the codepage in the text file record was set
accordingly, or whether the information was not available, is very
important for further processing (as an example, the programmer may ask
the end user to provide information about the text file encoding in
such
a case). Purely from technical point of view, it would be possible to
change it to a procedure and move the return value to a new actual
parameter, but it doesn't make much sense from my point of view.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
