Fehlende Sprachfeatures

[JamesTKirk]

Zitat von Stevie:

Da ja seit dem Release von Lazarus 1.0 ein regelrechter Hype losgebrochen ist, stell ich mir die Frage, inwieweit an den gegenüber Delphi (2010 oder neuer) fehlenden Sprachfeatures gearbeitet wird.

Gibt es da einen derzeitigen Stand (wenn ich mich nicht irre, gibt es ja einige Member hier, die diesbzgl aktiv sind)?

Damit bin wohl (u.a.) ich gemeint.

Zitat von Stevie:

Speziell für mich interessant wären Enhanced RTTI und anonyme Methoden.

Aaaalllso. *Ärmel hochkrämpelt*

Bei Enhanced RTTI und anonymen Methoden gibt es noch nichts im Trunk (also der Entwicklungsversion).

Vor einiger Zeit hat jedoch jemand drittes damit begonnen anonyme Methoden in einem Branch zu implementieren, dessen Aktivitäten sind jedoch wieder eingeschlafen. Vielleicht muss ich ihn mal fragen, ob er noch weitermachen möchte und wenn nicht muss ich selbst mal schauen das fertig zu bekommen.

An der Enhanced RTTI arbeitet zur Zeit noch niemand, wäre jedoch ne Idee, dass ich mal da dran arbeite, sobald ich mit Generics und Helpern halbwegs fertig bin.

Was mich gleich zu weiteren Features bringt:

• is und as für Interfaces werden bereits seit mindestens 2.6.0 unterstützt
• ein weiterer FPC Entwickler arbeitet derzeit an Attributen
• in 2.7.1 hat sich (dank mir ) vieles in Sachen Generics und deren Kompatibilität zu Delphi getan, einige Sachen fehlen jedoch noch, an denen ich in nächster Zukunft arbeiten werde: Generic Constraints, Generic Functions/Methods (ja, FPC wird auch globale generische Funktionen unterstützen), Nested Generics, Nested Specializations (z.B. TMyList<TMyContainer<String>>), bessere Unterstützung für Inline Specializations (mich grauts bereits davor...)
• class und record helper sind (in 2.6.0) auf dem Stand von Delphi XE2 (da sich bis dahin nicht allzuviel getan hat). Type helper (also die aus Delphi XE3) sind von mir geplant (ich habe bereits eine Proof of Concept Implementierung am Laufen)
• Advanced records sind in 2.6.0 implementiert mit der Ausnahme von Konstruktoren
• der Codepage Aware AnsiString ist in 2.7.1 vorhanden, String wurde jedoch noch nicht nach UnicodeString geändert (es existiert jedoch ein Modeswitch, mit dem man das machen kann, aber noch ist dessen Verwendung nicht wirklich empfehlenswert...)
• delay; wird auch nicht unterstützt (ich weiß aber auch niemanden, der aktiv daran arbeitet oder es sich wünscht)

Das müsste das insoweit zusammen fassen.

Zitat von Stevie:

Zu enhanced RTTI: wäre jetzt schon möglich, eine gewisse Kompatibilität zu erreichen, was die API angeht und sofern benötigte type information vorhanden ist (glaube aber, die ist noch auf dem Stand von Delphi 7? sprich nur published member).

Die Unit RTTI hat das Problem, dass sie auch teilweise auf Generic Methods setzt, welche ich wie geschrieben jedoch erst noch implementieren muss. Außerdem dürfte die Implementierung der RTTI Daten an sich nicht sooooo schwierig sein. Es muss halt nur mal einer machen.

Gruß,
Sven

[Stevie]

Danke für deine ausführliche Erläuterungen zum derzeitigen Stand.

Speziell zur RTTI stelle ich mir dann die Frage, wie es mit den Stellen aussehen wird, bei denen man um asm nicht mehr herum kommt bzgl der verschiedenen Targets.

Eine weitere Sache, die für mich interessant ist (im Hinblick auf eine FPC kompatible DSharp Version), inwieweit die API dann kompatibel sein wird. Könnt ihr euch die bei Delphi abschauen (Lizenz?) oder wie läuft das dann? Was ich auf keinen Fall machen werde, ist tonnenweise ifdefs in meinem Code verstreuen, um FPC zu unterstützen.

[JamesTKirk]

Zitat von Stevie:

Speziell zur RTTI stelle ich mir dann die Frage, wie es mit den Stellen aussehen wird, bei denen man um asm nicht mehr herum kommt bzgl der verschiedenen Targets.

Wie genau meinst du das? Die RTTI Funktionalität besteht doch im Endeffekt nur aus High Level Funktionen/Methoden? Intern wird natürlich - falls nötig - für die Plattform passender Assemblercode (zum Beispiel aller Wahrscheinlichkeit nach für RTTI.Invoke ) verwendet, aber das sollte den normalen Benutzer nicht wirklich tangieren...

Zitat von Stevie:

Eine weitere Sache, die für mich interessant ist (im Hinblick auf eine FPC kompatible DSharp Version), inwieweit die API dann kompatibel sein wird. Könnt ihr euch die bei Delphi abschauen (Lizenz?) oder wie läuft das dann? Was ich auf keinen Fall machen werde, ist tonnenweise ifdefs in meinem Code verstreuen, um FPC zu unterstützen.

Wir orientieren uns was Schnittstellen angeht an der Hilfe von Delphi (zum Beispiel die Delphi Referenz im Wiki von Embarcadero). Hiermit stellen wir sicher, dass einerseits so gut wie möglich Delphi Kompatibilität besteht und wir andererseits nicht Embarcaderos Copyright verletzen (Schnittstellen allein fallen ja nicht unters Copyright). Ich selbst verwende zum Beispiel genau aus diesem Grund die XE Starter für Tests, damit ich nicht in die Verführung komme in die Implementierung der RTL zu schauen. Die Korrektheit der Implementierung wird dann durch Tests sichergestellt, welche sowohl unter Delphi als auch unter FPC kompilieren/laufen können. Die Kompatibilät zu Delphi wird nur in Ausnahmefällen (zum Beispiel historische Gründe oder Multiplattformfähigkeit) gebrochen.

Gruß,
Sven

[Stevie]

Zitat von JamesTKirk:

Wie genau meinst du das? Die RTTI Funktionalität besteht doch im Endeffekt nur aus High Level Funktionen/Methoden? Intern wird natürlich - falls nötig - für die Plattform passender Assemblercode (zum Beispiel aller Wahrscheinlichkeit nach für RTTI.Invoke ) verwendet, aber das sollte den normalen Benutzer nicht wirklich tangieren...

Fraglich ist halt, ob gleich jede Plattform supported wird. Außerdem gibt es nach wie vor einige größere Unterschiede, wenn man sich in solchen Bereichen wie RTTI bewegt (hab z.B. nicht die ObjAuto.pas in FPC gefunden).

[JamesTKirk]

Zitat von Stevie:

Zitat von JamesTKirk:

Wie genau meinst du das? Die RTTI Funktionalität besteht doch im Endeffekt nur aus High Level Funktionen/Methoden? Intern wird natürlich - falls nötig - für die Plattform passender Assemblercode (zum Beispiel aller Wahrscheinlichkeit nach für RTTI.Invoke ) verwendet, aber das sollte den normalen Benutzer nicht wirklich tangieren...

Fraglich ist halt, ob gleich jede Plattform supported wird. Außerdem gibt es nach wie vor einige größere Unterschiede, wenn man sich in solchen Bereichen wie RTTI bewegt (hab z.B. nicht die ObjAuto.pas in FPC gefunden).

Das Generieren der RTTI Daten ist ziemlich plattformunabhängig, bzw. wird eh bereits passend für die "normale" RTTI gemacht, also muss das nur entsprechend angepasst werden. Der Rest ist dann einfach passend auf die Daten zuzugreifen. So viel Assembler dürfte da am Ende gar nicht nötig sein (ich glaub die aktuelle RTTI braucht sogar gar kein Assembler).

Bei den Punkten, bei denen Assembler nötig wird (also hier vor allem wieder RTTI.Invoke ), kann es natürlich sein, dass zuerst nur die Hauptplatformen (sprich x86, x86_64 (evtl. mit extra Code für Win64) und ARM) drankommen, aber die anderen sollten dann früher oder später folgen. Hier ist halt vor allem das Problem, dass nicht jeder gleich firm mit den verschiedenen Prozessoren ist. Ich selbst hätte zum Beispiel kaum Probleme mit x86 und x86_64, aber bereits mit ARM schaut die Sache ganz anders aus, von Sparc, PowerPC(64), MIPS(64) oder AVR ganz zu schweigen. Das müsste dann also jemand anderes machen (unter der Annahme, dass ich da was implementiere).

Was ist denn diese ominöse ObjAuto -Unit? Die höre ich heute zum ersten Mal...

Edit: Ok, ich hab nachgeschaut. Die ObjAuto -Unit fällt für mich in das gleiche Säckerl wie Extended RTTI und Attribute. Alles Features, die erst mit Delphi 2009 und neuer hinzugekommen sind. Sie stehen auf der Agenda, aktuell arbeitet jedoch (meist) keiner dran.

Gruß,
Sven

[Stevie]

Zitat von JamesTKirk:

Edit: Ok, ich hab nachgeschaut. Die ObjAuto -Unit fällt für mich in das gleiche Säckerl wie Extended RTTI und Attribute. Alles Features, die erst mit Delphi 2009 und neuer hinzugekommen sind. Sie stehen auf der Agenda, aktuell arbeitet jedoch (meist) keiner dran.

ObjAuto.pas gibt es schon seit mindestens Delphi 7.

[JamesTKirk]

Zitat von Stevie:

Zitat von JamesTKirk:

Edit: Ok, ich hab nachgeschaut. Die ObjAuto -Unit fällt für mich in das gleiche Säckerl wie Extended RTTI und Attribute. Alles Features, die erst mit Delphi 2009 und neuer hinzugekommen sind. Sie stehen auf der Agenda, aktuell arbeitet jedoch (meist) keiner dran.

ObjAuto.pas gibt es schon seit mindestens Delphi 7.

Delphi 6 scheint sie zumindest noch nicht zu enthalten (auch wenn hier eine ObjAuto.pas von Embarcadero zur Verfügung gestellt wird, die auch unter Delphi 6 funktionieren soll).

Die ganze Funktionalität scheint im Zusammenhang mit {$methodinfo ...} (siehe hier) zu stehen, welches von FPC auch nicht unterstützt wird.

Allgemein scheint diese Funktionalität nicht ganz so häufig verwendet zu werden, da ich wie gesagt heute zum ersten Mal davon gehört habe und ich auch bei den FPC Mailing Listen bisher noch nichts dazu gelesen habe. Dies bedeutet jedoch nicht, dass wir dafür keine Unterstützung einbauen würden Vielleicht kann man das ganze auch gleich kombinieren, so dass die Extended RTTI und die ObjAuto auf die selben Daten zugreifen...

Gruß,
Sven