On 15/09/2011 19:36, Hans-Peter Diettrich wrote:
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.
Thank you for ripping the above out of context. Now that it stands
outside it's original context => you are right, now the contrary is true.
Of course, when it still was in it's context.....
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.
This is true as far as the comparison between utf8 and utf16 goes. All
other problems were ignored, because the point was ONLY to compare
between the 2. Any othr alternative, or any change caused by either of
them was not part of the statement.
Utf16 does have surrogate pairs as well as chars not in the bmp
That means any developper who is serious about it's work must implement
the handling of those. Which makes the effort comparable to utf8.
Yes indeed you are right, the chances that something goes wrong, if a
developper doesn't deal with them are considerable lower in utf16 than
in utf8 (but they do exist) => that was exactly my point.
If there is a likelyhood for a certain error to be made (by accident)
then it is better if th chnaces are high that you notice the error =>
otherwise you ship your software with the error, and spend long time
figuring out the bug reports from you users.
Of course, if a programmer INTENTIONALLY puts this error in his code,
hoping to get away with it, then utf16 is the better choice.
I can and will however not see such bad practice as an argument for the
case.
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.
please re-read my statement. Your statement seems to confirm not
contradict mine
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel