On 2019-09-06 15:22, Tomas Hajny wrote:
On 2019-09-06 07:24, LacaK wrote:
Hi *,
As promised, I discussed the idea of adding support for UTF-16 encoded
text files (and preferably UTF-32 as well while at it) to the RTL with
other core team members. Overall, I didn't come across anybody oposin
Tomas-
Thanks for pursuing this! Generally a good approach.
I do not like item 3 in that the function, as described, is named DetectUtfBom
but does more than detect. Side effects of functions are generally not good. I
would at least rename it something like DetectAndHandleUtfBom.
But to
On 2019-09-16 00:29, DougC wrote:
Doug,
.
.
I do not like item 3 in that the function, as described, is named
DetectUtfBom but does more than detect. Side effects of functions are
generally not good. I would at least rename it something like
DetectAndHandleUtfBom.
Take the provided names j
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.
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
Hi *,
As promised, I discussed the idea of adding support for UTF-16 encoded
text files (and preferably UTF-32 as well while at it) to the RTL with
other core team members. Overall, I didn't come across anybody oposing
this idea, the only (logical) requirement is taking care of the
perform
On Sun, 15 Sep 2019, 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, retur
