Fehlende Sprachfeatures

[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)?

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

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).

[himitsu]

Die alte RTTI geht nur auf public/publisches Fields/Methodes.
In der neuen erweiterten RTTI sind (falls man es nicht explizit ausschaltet) sogar "private"- und "strict private"-Dinge enthalten.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1184242)

Die alte RTTI geht nur auf public/publisches Fields/Methodes.
In der neuen erweiterten RTTI sind (falls man es nicht explizit ausschaltet) sogar "private"- und "strict private"-Dinge enthalten.

Du hast gesehen, in welchem Unterforum wir sind, oder?

[himitsu]

Nö :lol:

[Neutral General]

Wobei ich sagen muss, dass mich der Text oben auch irritiert hat und ich deinen Post 3x lesen musste bevor ich gemerkt habe dass es hier nicht um Delphi geht. Mit dem Stichwort "Freepascal" im Titel oder in deinem Ausgangspost gäbe es da wahrscheinlich nicht so viel Verwirrung ;)

[himitsu]

Vielleicht können wir Danel ja dazu überreden, ein paar Unterforen irgendwie hervorzuheben.

Wie wäre es mit Pink als Hintergrundfarbe beim FreePascal?
(oder einem rötlichem "(FreePascal)" hinter der Überschrift jedes Posts)

[JamesTKirk]

Zitat:

Zitat von Stevie (Beitrag 1184237)

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. :mrgreen:

Zitat:

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:

• Delphi-Quellcode:

  is

  und
  Delphi-Quellcode:

  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 :D ) 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,
  Delphi-Quellcode:

  String

  wurde jedoch noch nicht nach
  Delphi-Quellcode:

  UnicodeString

  geändert (es existiert jedoch ein Modeswitch, mit dem man das machen kann, aber noch ist dessen Verwendung nicht wirklich empfehlenswert...)
• Delphi-Quellcode:

  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:

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:

Zitat von Stevie (Beitrag 1184312)

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

Delphi-Quellcode:

RTTI.Invoke

) verwendet, aber das sollte den normalen Benutzer nicht wirklich tangieren...

Zitat:

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:

Zitat von JamesTKirk (Beitrag 1184320)

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

Delphi-Quellcode:

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).