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