[fpc-devel] Unicode support (yet again)
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Thu Sep 15 20:36:26 CEST 2011
Martin schrieb:
> On 15/09/2011 10:38, Michael Schnell wrote:
>> On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote:
>>>
>>> and to show you AGAIN how flawed your "direct index access to a
>>> character" example is.
>> It's not "my" intend to use it. I'll never use it as I do know that it
>> is bound to create problems. But it is what generations of pascal
>> programmers are trained to do. They all need to be re-trained. In fact
>> this is just "Syntax-Candy" (as here native Array-syntax is used for a
>> non-array type). So it could be removed or modified to better support
>> the expectation of the "generations of pascal programmers" even in
>> times of Unicode.
>
> Which imho makes utf8 far more preferable than utf16
Just the contrary is true. UTF-16 extends the range of usable charsets,
with only changing the size of a char.
> in UTF8 the error is bound to happen far easier, which gives people a
> far better chance to catch it before release, even before creating to
> much code relying on the buggy implementation.
> Certain errors will be made, the importance is not, to create an
> environment in which they can not be made. The importance is to create
> an environment in which they will be caught as early as possible.
This is true only for formal errors, not for all the other problems with
foreign languages. The assumption, that Unicode will turn every coder
into an linguist, capable of dealing with all (human) languages, is
simply wrong.
> And besides that "generations of pascal programmers". Well the older
> ones are 9or at least should be) experienced => they should have no
> problem learning it. programming requires a developer to keep up to
> date. (I for example have long given up to directly access the video
> memory of a VGA adapter, despite my generation was trained to do so)
>
> As for "newbies" => they come with all kind of wrong experiences. A lot
> of them come from VBA, and yet we aren't discussing introduction of VBS
> like object instantiation? ( variable.Create instead of
> variable:=class.create).
> so again, utf8 is good, they make the error, they see the error, they
> learn.
VBA uses UTF-16, proofing your assumptions as wrong again.
DoDi
More information about the fpc-devel
mailing list