UFT8 a[3] := b[3]

[mse]

[OT]
Was ich nicht so ganz verstehe, warum viele Lazarus Anwender so empfindlich auf Kritik, Änderungs-Wünsche und -Vorschläge reagieren. Warum ist alles Bestehende an Lazarus sakrosankt? Ist der sich im Namen widerspiegelnde religiöse Hintergrund die Ursache? Eine offene Auseinandersetzung kann doch zur Produktequalität nur beitragen?
Natürlich verstehe ich den Besitzerstolz, den kenne ich selbstverständlich auch, aber trotzdem...

Martin

[marcov]

Sollen sie also erst mal auf das aktuelle Delphi.....

Kein Problem! Wo kann ich die Rechnung her schicken?

[marcov]

Ich sehe nicht, dass Lazarus da ein Problem hat.

Ehem, dies ist doch eine etwas sehr einseitige Sicht der Dinge.
Vor allem, wenn man daran denkt, dass es Alternativen zum gewählten Lazarus String-System gegeben hätte und immer noch gibt. Am Anfang mehr Arbeit für die Lazarus Entwickler, dafür mehr Komfort für die Lazarus Anwender und letztendlich auch wieder weniger Arbeit für die Lazarus Entwickler.

Die gibt es noch nicht. Widestring ist D2007- VCL inkompatibel, und unicodestring ist noch nicht fertig.

[mse]

Die gibt es noch nicht. Widestring ist D2007- VCL inkompatibel.

"utf-8 in AnsiString, kein BOM, kein {$codepage utf8}, kein -Fcutf8" ist ebenfalls VCL inkompatibel AFAIK.

[marcov]

Die gibt es noch nicht. Widestring ist D2007- VCL inkompatibel.

"utf-8 in AnsiString, kein BOM, kein {$codepage utf8}, kein -Fcutf8" ist ebenfalls VCL inkompatibel AFAIK.

Es ist auch niemals als endgültige Lösung gemeint, nur bis echte UTF-8 Unicode Typs addiert werden.

Das ist alles so gemeint das Nutzer nur durch EINE große Migration gehen müssen, stat zwei.

[theo]

Was ich nicht so ganz verstehe, warum viele Lazarus Anwender so empfindlich auf Kritik, Änderungs-Wünsche und -Vorschläge reagieren. Warum ist alles Bestehende an Lazarus sakrosankt? Ist der sich im Namen widerspiegelnde religiöse Hintergrund die Ursache? Eine offene Auseinandersetzung kann doch zur Produktequalität nur beitragen?

Weil's im Moment nichts bringt. Das Problem muss eindeutig im FPC Code gelöst werden, dann kann man mit der LCL nochmal über die Bücher.
Ausserdem hat die Kritik, wenn sie von dir kommt, immer den Beigeschmack von msegui Promo und das nervt

[mse]

Das ist alles so gemeint das Nutzer nur durch EINE große Migration gehen müssen, stat zwei.

Einverstanden.
Bei MSEgui war die Migration aus "vor MSEgui Zeiten" AnsiString -> msestring, char -> msechar.
msechar = widechar, msestring = WideString bis und mit FPC 2.2.4, msestring = UnicodeString ab FPC 2.4. Dank Widestringmanager war die Migration für die Anwender relativ schmerzlos, Dank diverser FPC Widestring-bugs für den Toolkit Entwickler eher nicht.
Etwas Ähnliches sollte doch auch mit Lazarus möglich sein?

[marcov]

Das ist alles so gemeint das Nutzer nur durch EINE große Migration gehen müssen, stat zwei.

Einverstanden.
Bei MSEgui war die Migration aus "vor MSEgui Zeiten" AnsiString -> msestring, char -> msechar.
msechar = widechar, msestring = WideString bis und mit FPC 2.2.4, msestring = UnicodeString ab FPC 2.4. Dank Widestringmanager war die Migration für die Anwender relativ schmerzlos, Dank diverser FPC Widestring-bugs für den Toolkit Entwickler eher nicht.
Etwas Ähnliches sollte doch auch mit Lazarus möglich sein?

Wenn Lazarus das getan hatte gleich mit MSE, dann würde es lang Delphi inkompatible gewesen. Das ist mit der heutige Lösung weniger.

Auch forciert mann zo alle Leute nach UTF16 Lösung, ohne Migration. Bestehende FPC/Lazarus user (mit ascii Kodebases), Unix Zentrische und Klassisch Delphische User last mann mit solche UTF-16 "BigBang" Lösung allein.

Delphi hat das getan weil sie
- Windows-only (oder -Zentrisch) sind, und
- kein compiler modes haben
- BigBang für Codegear und Partner günstig ist um Upgrades zu forcieren von Leute die noch immer auf D6/D7 sein.

Wie es endlich sein wird, ist noch nicht klar. Zuerst soll FPC fertig sein, und muss Lazarus einige Lösungen testen zu werden. Dan kann Lazarus wählen.

Heut sieht das so aus:
Also FPC wird ein D2009 Modus haben. (mit string=unicodestring) _IMMER_
Vielleicht noch ein Switch ähnlich zu {$H+} fuer string =utf8string.

Aber der Planung für diese Funktionalität ist dunkel. Seit den originelle Unicodestring Support ist dort nicht viel mehr passiert. (an Interessierten: HINT,HINT)

Dennach müssen FPC und Lazarus sich (beide, FPC fuer RTL, Lazarus fuer LCL) entscheiden, ob sie UTF16 oder UTF8 für Unix nehmen. Heute sind die Devels sich darüber noch nicht einig.

(Ich selber denk dass UTF16 fuer RTL auf Linux unsinnig und Katastrophal ist. Ein UTF-16 LCL mag ich auch GAR nicht, aber ist ein bisschen weniger Schlimm)

P.s. Ich bin mich mit Theo einig über den MSE promo. MSE hat kein Legacy, kein Komptabilität (sonder eigen-) usw Bedingen. Mann kann dann deshalb gar nicht vergleichen mit Lazarus die die Bedingen schon hat, und dann hört es sich an als MSE promo.

[mse]

Wenn Lazarus das getan hatte gleich mit MSE, dann würde es lang Delphi inkompatible gewesen. Das ist mit der heutige Lösung weniger.

Nicht einverstanden. utf-8 <-> Ansi ist in der Praxis weniger kompatibel als Ansi <-> WideString/UnicodeString mit Widestringmanager.

(Ich selber denk dass UTF16 fuer RTL auf Linux unsinnig und Katastrophal ist.

Einverstanden. Die RTL sollte grundsätzlich mit der System-Codierung arbeiten. Auf Windows ist dies zwar utf-16 aber dies ist wieder ein anderes Problem...

Ein UTF-16 LCL mag ich auch GAR nicht,

Nicht einverstanden. Die LCL sollte platformunabhängig die für die Anwender bequemste Codierung verwenden. Dies ist in den allermeisten Fällen ausser für die USA UCS2/utf16.

P.s. Ich bin mich mit Theo einig über den MSE promo. MSE hat kein Legacy, kein Komptabilität (sonder eigen-) usw Bedingen. Mann kann dann deshalb gar nicht vergleichen mit Lazarus die die Bedingen schon hat, und dann hört es sich an als MSE promo.

Gerade darum ist MSEide+MSEgui bestimmt keine Konkurenz für Lazarus sondern eher eine "Bereicherung" für FPC, obwohl das Erscheinen von MSEide+MSEgui die Lazarus-Entwicklung möglicherweise beschleunigt hat.
Die MSEgui Entwicklung startete ca. 1999 und hat also auch schon einigen "Legacy-Abwurf" hinter sich.

Edit:
Mit der Aufteilung RTL = System Codierung, LCL = WideString besteht meiner Meinung nach auch kein zwingender Bedarf mehr für die Implementierung eines SuperUnicodeString mit Codierungsfeld und automatischer Konvertierung.

[mschnell]

Konkurrenz ?!?!?!?!?!?

Im Open-Source-Bereich gibt es doch eigentlich nur Bereicherung, weil jeder ja bei Bedarf beim anderen klauen darf.

-Michael

[theo]

Laber, laber, laber....

Ich fasse zusammen:
Vor der Implementierung der D 2009 Kompatibilität in FPC / RTL, ergeben Änderungen in der LCL keinen Sinn. Schnellschüsse würden jetzt nur nerven und wären Energieverschwendung.

Man kann ja vielleicht sogar was dafür tun, dass sich der Prozess beschleunigt (statt zu jammern).
Florian hat mich bspw. gefragt, ob er meine character.pas als Basis für die Implementierung von TCharacter nehmen kann.
http://bugs.freepascal.org/view.php?id=14598" onclick="window.open(this.href);return false;
Ob er's gebrauchen kann, weiss ich nicht. Aber besser als nörgeln ist das.

[mse]

Laber, laber, laber....

Nun, wenn du die Quintessenz meiner in mehr als zehn Jahren gemachten Erfahrungen als Gelaber empfindest...

[theo]

Nun, wenn du die Quintessenz meiner in mehr als zehn Jahren gemachten Erfahrungen als Gelaber empfindest...

Ach komm, das nehm ich dir nicht ab, dass die Quintessenz deiner Erfahrungen die Parole "UCS-2 statt UTF-8" ist.
Das ist ja schon fast wie "42"
http://en.wikipedia.org/wiki/Minor_char ... ep_Thought" onclick="window.open(this.href);return false;

[marcov]

Wenn Lazarus das getan hatte gleich mit MSE, dann würde es lang Delphi inkompatible gewesen. Das ist mit der heutige Lösung weniger.

Nicht einverstanden. utf-8 <-> Ansi ist in der Praxis weniger kompatibel als Ansi <-> WideString/UnicodeString mit Widestringmanager.

Nicht einverstanden. utf-8 <-> ansi is einfacher wenn man nur hier und da unicode nutz (etwa im userinterface).

Und wenn man voll geht, macht das nichts aus.

(Ich selber denk dass UTF16 fuer RTL auf Linux unsinnig und Katastrophal ist.

Einverstanden. Die RTL sollte grundsätzlich mit der System-Codierung arbeiten. Auf Windows ist dies zwar utf-16 aber dies ist wieder ein anderes Problem...

Ein UTF-16 LCL mag ich auch GAR nicht,

Nicht einverstanden. Die LCL sollte platformunabhängig die für die Anwender bequemste Codierung verwenden. Dies ist in den allermeisten Fällen ausser für die USA UCS2/utf16.

Ein Codierung, eben wenn das Platform (und wichtiger, die Widget sets) eine andere Nutzen ist jetzt unbequem. Wenn ich eine Windows emulation mag, nutze ich Wine(lib). Wenn ich eine Emulation möchte der mir ganz von der Realität abschirmt, wurde ich Java nutzen.

FPC/Lazarus functionieren nicht so.

Daneben bin ich nicht überzeugt, das UTF-16 im Ende wirklich einfacher ist.

P.s. Ich bin mich mit Theo einig über den MSE promo. MSE hat kein Legacy, kein Komptabilität (sonder eigen-) usw Bedingen. Mann kann dann deshalb gar nicht vergleichen mit Lazarus die die Bedingen schon hat, und dann hört es sich an als MSE promo.

Gerade darum ist MSEide+MSEgui bestimmt keine Konkurenz für Lazarus sondern eher eine "Bereicherung" für FPC, obwohl das Erscheinen von MSEide+MSEgui die Lazarus-Entwicklung möglicherweise beschleunigt hat.

Das war nicht das Problem. Die quote war in einer Diskussion der Lazarus gleicht mit MSE. Und das ist falsch.

Mit der Aufteilung RTL = System Codierung, LCL = WideString besteht meiner Meinung nach auch kein zwingender Bedarf mehr für die Implementierung eines SuperUnicodeString mit Codierungsfeld und automatischer Konvertierung.

Ich denke, mann braucht gar kein UTF-16 auf Linux
Wenn UTF-8 da ist, kan mann widestring und unicodestring windows only machen. (resp fuer COM und LCL/win32/64)

[mse]

Ich denke, mann braucht gar kein UTF-16 auf Linux
Wenn UTF-8 da ist, kan mann widestring und unicodestring windows only machen. (resp fuer COM und LCL/win32/64)

OK, ich gebe es auf, macht was ihr wollt.

Martin