Störende Elemente der Delphi-Syntax / Vorschläge für neuen Dialekt

[implementation]

Hallo liebe Delphisten,

im Laufe der Zeit haben sich bei mir einige Dinge angehäuft, die mich an der aktuellen Syntax von Object Pascal stören.
Darunter sind folgende:

• Es muss eine strikte Reihenfolge von interface->implementation eingehalten werden. Das heißt, ich kann keine globale Eigenschaft deklarieren, die auf eine private Variable zurückgreift.
• Interfaces sind per se immer an Referenzzählung und COM-Kompatibilität gebunden. In meinem halbjährigen Ausflug nach C# habe ich erfahren, wie schön es sein kann, a) in Interfaces für Properties nicht gleich eine Getter/Setter-Methode angeben zu müssen, sondern dies der Implementierung zu überlassen, b) Objekt- und Interfacereferenzen mischen zu können
• Methoden und nichtmethodische Routinen sind im implementation-Teil sprachlich nicht gruppiert (höchstens durch Kommentare)
• Man kann zwar mehrere verschiedene benannte Destruktoren deklarieren, das hilft aber nichts, weil Free immer nur einen ganz bestimmten aufruft. Wozu haben wir denn unser schönes Benennungsfeature?

Daher habe ich mir mal einen Entwurf für einen neuen kleinen Dialekt überlegt, der diese Dinge besser machen soll, ich nenne ihn bisher "Thrym".

Hier mal ein Ausschnitt:

Delphi-Quellcode:

// Thrym

unit sample;

// Uses-Klausel außerhalb von public/private/implementation
uses
  ...

// public + private statt interface
public

  type
    TExample = class
    public
      procedure Sample;
    end;
    
    // Counted Interfaces:
    //   Klassische COM-Interfaces, auf Methoden beschränkt,
    //   Properties gehen den Weg über diese
    //   (Referenzzählung!!)
    IExample = counted interface
      ['{GUID}']
      procedure SetTest(AValue: Integer);
      function GetTest: Integer;
      property Test: Integer read GetTest write SetTest;
    end;
    
    // Uncounted Interfaces:
    //   Von COM komplett unabhängig, keine Referenzzählung
    //   Properties müssen nicht direkt einen Getter/Setter
    //   zugewiesen bekommen, dies ist Sache der Implementierung
    //   Implementierende Klassen müssen nicht AddRef/Release/
    //   QueryInterface unterstützen
    ISample = uncounted interface
      property Test: Integer read write;
    end;
    ...
  
  const
    ...
    
  var
    ...
    
private

  type
    // Schema-Typ, wie in GPC:
    TCharArray(start, length: Integer) = array [start..start+length] of char;
    TSample = TCharArray(0,6);
    ...
    
  const
    ...
    
  var
    ...
    FProp: Integer;
    
// können auch mehrere public/private sections sein
public

  // z.B. um global properties besser zum ermöglichen
  property Prop: Integer read FProp write FProp;
  
implementation // oh, it's me!

  // In den Implementation-Teil kommt
  // tatsächlich nur noch die Implementierung
  // der im public- und private-Teil deklarierten
  // Methoden und nichtmethodischen Routinen

  // Methoden gruppieren nach Klasse
  TExample: begin
  
    procedure Sample;
    var obj: TExampleObject;
    begin
      obj := TExampleObject.Create;
      try
        // Do Something
      finally
        // den Destruktor gefahrenlos direkt aufrufen können
        // damit benannte Destruktoren auch endlich wieder Sinn
        // machen - wozu kann man sonst mehrere Destruktoren
        // deklarieren, wenn man eh nur Destroy über Free verwenden
        // kann
        obj.Destroy;
        // schön wäre es jetzt noch, wenn obj gleich auf Nil gesetzt würde
        // dazu aber dick: Fragezeichen ?
      end
    end;
  
  end;

end.

Nun möchte ich das ganze aber nicht einfach verschlimmbessern, daher Frage an euch: Was haltet ihr von diesen Änderungen, insbesondere dem automatischen nil-setzen?

Je nach Feedback setze ich das ganze vllt. in Zukunft mal durch einen Präcompiler um, der dies dann in FreePascal-Code oder Delphi-Code umschreibt.

Verbesserungsvorschläge, Kritiken und Featurerequests sind gern willkommen (dazu mache ich den Thread ja auf :stupid:)

[shmia]

Zitat:

Zitat von implementation (Beitrag 1145448)

Man kann zwar mehrere verschiedene benannte Destruktoren deklarieren, das hilft aber nichts, weil Free immer nur einen ganz bestimmten aufruft. Wozu haben wir denn unser schönes Benennungsfeature?

Ein Klasse kann grundsätzlich nur einen Destruktor haben.
Es mag verschiedene Arten geben ein Objekt zu erzeugen aber es gibt nur eine Art es zu zerstören.
Das gilt IMHO für alle OO Programmiersprachen.
In Delpi muss der Destruktor immer so deklariert werden:

Delphi-Quellcode:

destructor Destroy;override;

Jeder Abweichung von dieser Deklaration führt zu einem nicht funktionierenden Destruktor.

[implementation]

Danke schonmal für dein Feedback!

Zitat:

Zitat von shmia (Beitrag 1145467)

Jeder Abweichung von dieser Deklaration führt zu einem nicht funktionierenden Destruktor.

Eben das ist ja das, was mich stört. Man kann auch weitere Destruktoren deklarieren, aber die tuns dann nicht so, wie sie sollen.
Was ist, wenn ich eine Objektliste deklarieren will, und zwei verschiedene Destruktoren möchte: Einer, die die Objekte mitfreigibt, und einer, der dies nicht tut. Momentan wäre das auf diese Weise so nicht wirklich machbar.

Wir haben in Object Pascal benannte Destruktoren, wir können sie nur nicht anständig nutzen. Und das stört mich, deshalb möchte ich es in Thrym besser machen.

Zitat:

Das gilt IMHO für alle OO Programmiersprachen.

In den meisten Sprachen kann man Con- und Destruktoren auch nicht benennen.

[shmia]

Zitat:

Zitat von implementation (Beitrag 1145470)

Zitat:

Zitat von shmia (Beitrag 1145467)

Jeder Abweichung von dieser Deklaration führt zu einem nicht funktionierenden Destruktor.

Eben das ist ja das, was mich stört. Man kann auch weitere Destruktoren deklarieren, aber die tuns dann nicht so, wie sie sollen.

Ah ok - da müsste der Compiler doch einfach nur auf jede Abweichung von der richtigen Destruktor-Signatur mit einem Compilerfehler reagieren.
Das Problem von Delphi ist, dass der Destruktor überhaupt einen Namen bekommen hat.
Man hätte das z.B. auch so machen können:

Delphi-Quellcode:

TEineKLasse = class(TBasisKlasse)
...
public
  constructor Create;
  destructor;
end;

destructor TEineKLasse;
begin
  ...
  inherited;
end;

// und statt Destroy oder Free würden man Objekte so freigeben:
Dispose(einObjekt);

[implementation]

Genau, so habe ich mir das zunächst auch gedacht, als mir das Problem bewusst wurde.
Aber warum nicht den "Bug" zum Feature machen ;)
Im oben erwähnten Beispiel mit der Objektliste hielte ich es für sehr sinnvoll, zwei verschiedene Destruktoren zu haben.


Das zweite Destruktor-Problem ist, dass man ihn nicht direkt aufrufen sollte, weil's Crash geben kann. Und was macht man da? Dem Destruktor die gleiche Funktionalität der Free-Methode geben, ist mein bisheriger Vorschlag.

[EDIT] Ah, jetzt erst das Dispose bei dir gesehen. Das ist auch ein sehr guter Vorschlag, da hätte man es gleich einheitlich mit Pointern.

[Namenloser]

• Ich finde, man sollte Variablen immer bei der Deklaration initialisieren können, also nicht nur globale Variablen, sondern auch Felder und lokale Variablen.
  Delphi-Quellcode:

  var x: integer = 0

• Oft nervt mich die Operatoren-Priorität bei Konditionalen – dass man um Vergleiche immer eine Klammer setzen muss, wenn man sie per AND oder OR verknüpfen will. Ich kenne keine andere Sprache, wo das so ist.
  Delphi-Quellcode:

  if a<b and b<c then ...

  statt
  Delphi-Quellcode:

  if (a<b) and (b<c) then ...

  . Wann will man schon mal tatsächlich zwei Werte in einer Abfrage binär verknüpfen? Außerdem wäre das ja immer noch möglich, eben mit Klammerung. Ich wünschte mir hier einfach ein anderes Default.
• Ich fände es außerdem cool, wenn sowas ginge:
  Delphi-Quellcode:

  if a < b < c then ...

  . Ich glaube Prism/Oxygene kann das.
• Hin und wieder nervt mich, dass man im Interface-Bereich Felder immer vor Methoden deklarieren muss.
• Delphi-Quellcode:

  try ... except ... finally ... end

  statt zwei try-Blöcke schachteln zu müssen.
• Fände es manchmal cool, wenn man, wie in einigen Scriptsprachen, Bereiche von Arrays direkt per Sprachfeature herauskopieren könnte. Z.B.
  Delphi-Quellcode:

  myString[3:5]

  statt
  Delphi-Quellcode:

  Copy(myString, 3, 2)

  .
• Strings sollen gefälligst bei 0 anfangen wie ein anständiges Array, nicht bei 1!

Das fällt mir jetzt spontan so ein...

[Furtbichler]

Zitat:

Zitat von NamenLozer (Beitrag 1145507)

Strings sollen gefälligst bei 0 anfangen wie ein anständiges Array, nicht bei 1!

Das würde ich noch nicht einmal vorschlagen. Stell Dir vor, irgendein Guru denkt, das das ne gute Idee ist und führt es mit XE 4 ein... DAS wird lustig.

Ansonsten ist Delphi leider veraltet und hinkt. Das Handicap wird es auch nicht wieder los.

[Namenloser]

Zitat:

Zitat von Furtbichler (Beitrag 1145515)

Das würde ich noch nicht einmal vorschlagen. Stell Dir vor, irgendein Guru denkt, das das ne gute Idee ist und führt es mit XE 4 ein... DAS wird lustig.

Ansonsten ist Delphi leider veraltet und hinkt. Das Handicap wird es auch nicht wieder los.

Geht ja auch nicht um ernsthafte Wünsche für die Delphi-Language – klar, das wird man die Altlasten nicht mehr los. Aber das Thema heißt ja auch „Vorschläge für einen neuen Dialekt“.

[himitsu]

Delphi-Quellcode:

TCharArray(start, length: Integer) = array [start..start+length] of char;
TSample = TCharArray(0,6);

Sieht einfach nur häßlich aus und paßt nicht zur Pascal/Delphi-Syntax.

Was ich mir aber wünschen würde:
- die Generics so erweitern, daß man statt typen auch Konstanten verwenden kann.
(würde dann teilweise ähnliche Möglichkeiten bieten, wie die Makros in C)

- ein mehrstufiger Compiler, bzw. ein intelligenterer, so daß man besseren Zugriff auf die Typen hat, welche im denerischen Type enthalten sind.

- generische Prozeduren, Interfaces und Class Helper (nicht nur Klassen.Methoden)

- Class Helper Record Helper für einfache Basistypen, wie t.B. den Integer oder den String

- Interface Helper

- Operatoren für Interfaces

- Operatoren für Copy, Create und Destroy von Records
(technisch leicht möglich, da alle Struckturen schon existieren ... siehe Behandlung der Interfaces, dyn. Arrays und der Strings innerhalb von Records)

- endlich mal ein Versesserung einiger Grenzen in der OTA
(jbg bekommt auch immer wieder mit, daß Vieles einfach nur fehlt oder schecklich implementiert ist)

- und ein OTA-Interface für einen eigenen Precompiler

- daß man bei dyn. Arrays das CopyOnWrite aktivieren kann, so wie es bei den Strings auch vorhanden ist

- ein Continue und Break mit Ebenenangabe, so daß man mehrere Schleifen unterbrechen kann

- manchmal (ganz selten) hab ich mit schon eine kombinierte Try-Except-Finally-Stuktur gewünscht

- absolute mit einer Typsicherheits- und Größenprüfung (Compilerwarnung)

- string aus den reservierten Wörtern rausnehmen

- ein "caseend" für die varianten Recordteile ("end" geht ja nicht mehr ... das hätte man gleich zu Beginn nicht vergessen dürfen :wall:)

- das Strg+Linksklick auf einen generischen Teil (Methode,Feld,...) nicht bei "implementation" landet, sondern beim generischen Typen :roll:

- uvm.


Also nur Neuerungen/Verbesserungen, welche aber nicht die "alte" gewohnte Syntax beeinflussen




- eine bessere Informationspolitik seitens Emba, endlich mal eine ordentliche Emba-Webseite erwähn ich besser mal nicht :stupid:

Zitat:

Strings sollen gefälligst bei 0 anfangen wie ein anständiges Array, nicht bei 1!

Gut, das wäre mal praktisch, aber für Delphi leider nicht mehr möglich :oops:



Das zu den störenden Elementen und wenn, dann darf man das gerne auch in einer neuen Syntax verbauen.

[implementation]

Na das sind ja schonmal einige Punkte :thumb:

Zitat:

Zitat von himitsu (Beitrag 1145518)

Delphi-Quellcode:

TCharArray(start, length: Integer) = array [start..start+length] of char;
TSample = TCharArray(0,6);

Sieht einfach nur häßlich aus und paßt nicht zur Pascal/Delphi-Syntax.

Stimmt, sieht hässlich aus, wäre aber quasi die Lösung für:

Zitat:

- die Generics so erweitern, daß man statt typen auch Konstanten verwenden kann.

Vllt. aber dann doch lieber so schreiben:

Delphi-Quellcode:

TIrgendwas<type t; const a,b: Integer> = class
  ...
end;

Zitat:

Class Helper (nicht nur Klassen.Methoden) [...] Record Helper für einfache Basistypen [...] Interface Helper

Wäre es nicht schön, einfach ein Helperkonstrukt für alle Typen zu haben, statt zwischen Class-, Record und Interface-Helpern zu unterscheiden? Also sowas wie:

Delphi-Quellcode:

TXyz = helper for ...
  ...
end;

Zitat:

Operatoren für Interfaces

Bei Operatoren finde ich die FPC-/GPC-Syntax ganz schön, sie komplett aus der Klassendeklaration herauszunehmen. Dadurch wird jeder Typ operatorfähig, z.B.:

Delphi-Quellcode:

operator :=(const i: IMyInterface): string;

Zitat:

- ein "caseend" für die varianten Recordteile ("end" geht ja nicht mehr ... das hätte man gleich zu Beginn nicht vergessen dürfen :wall:)

Wie wäre es mit einer Trennung zwischen Record und Union?


Zu allem unkommentierten: Full Ack :thumb:

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1145518)

- Class Helper Record Helper für einfache Basistypen, wie t.B. den Integer oder den String

- Interface Helper

Achja genau, das hatte ich noch vergessen. Ich wäre einfach für einen allgemeinen

Delphi-Quellcode:

Helper

, für jeden Typ, egal ob Klasse, Record oder primitiver Datentyp wie Integer. Diese Unterscheidung von class helpern und record helpern ist redundant, weil der Datentyp, auf den sich der Helper bezieht, ja ohnehin klar ist. Und falls man mal aus einem Record eine Klasse macht oder umgekehrt, müsste man nicht auch noch zusätzlich alle Helper-Definitionen anpassen.

Delphi-Quellcode:

type
  TFormHelper = helper for TForm
    procedure FadeOut();
  end;

  TRectHelper = helper for TRect
    procedure Normalize;
    function ContainsPoint(Pt: TPoint): Boolean;
  end;
  
  TIntHelper = helper for Integer
    function ToString: string;
  end;

Damit wären sehr moderne Konstrukte und modulare Programmierung möglich.

[himitsu]

Zitat:

Zitat von implementation (Beitrag 1145530)

Wäre es nicht schön, einfach ein Helperkonstrukt für alle Typen zu haben, statt zwischen Class-, Record und Interface-Helpern zu unterscheiden?

Im Prinzip hast du ja Recht, denn über den Zieltüben ließe es sich ja unterscheiden.
Aber dann wäre es nicht mehr ganz kompatibel zum alten Code.

Zitat:

Bei Operatoren finde ich die FPC-/GPC-Syntax ganz schön, sie komplett aus der Klassendeklaration herauszunehmen. Dadurch wird jeder Typ operatorfähig,

Ein Operator Helper :angle2:

Für Objekte sind Operatoren leider nicht möglich, der fehlenden automatischen Speicherverwaltung wegen,
aber wenn man die Copy/Create/Destroy-Ereignisse einführt, würde es dennoch einen Weg geben. :angle:

[Medium]

Mein Wunsch geht zwar über Syntax hinaus, und dafür würden mich sicher hier gerne einige vermöbeln, aber ein Delphi mit GC wäre schon sexy. Ich weiss, es gibt da diverse Fummelein mit Interfaces und Hacks, aber ein richtiger "ab Werk" GC ist einfach eine riesen Komfortsteigerung (wenn er vernünftig umgesetzt ist). Was ich in C# ab und an gern mache, und in Delphi ab und an wünschte, ist sowas wie

Delphi-Quellcode:

lokaleVarMitRückgabewert := TMyFooClass.Create(aParameter).SomeMethod(aNotherParameter);

, und die Instanz dann einfach verpuffen lassen. (Ja, das sieht nach einem Designfehler aus, man meint die Methode hätte statisch sein sollen - aber so schlau sind leider nicht alle Fremdkomponentenhersteller.) Oder auch so Späße, bei denen Instanzen über mehrere Threads eher "locker umher geworfen" werden würden mit einem GC etwas weniger Kopfschmerzlastig.

Vielleicht sogar als alternativer Konstruktor, ggf. mit Einführung des new-Operators!

Delphi-Quellcode:

  bar := TMyFooClass.Create(); // <- normal ohne GC
  bar := new TMyFooClass(); // <- GC'ed

Mit etwas Unterstützung in der IDE (anderes Highlighting für GC'ed Instanzvariablen) wäre so ein Hybrid glaube ich sogar einigermaßen handlich.

[implementation]

@Medium:

Das ist eine verdammt gute Idee! Was mich an GC-Sprachen bisher insbesondere gestört hat, war, dass man den GC nicht einfach abstellen konnte. Ich habe über eine Hybridschiene schon nachgedacht, aber da bin ich immer zur Kollision gekommen.
Der Einfall, die Objekte einfach durch einen anderen Konstruktor zu erzeugen ist ein genialer Ansatz.

Das wäre allerdings ein Punkt, den ich allein nicht umsetzen könnte, weil ich a) von GC-Bau keinen Schimmer habe und b) auch keinen kenne, den man zu dem Zweck in die Ausgabedatei einfach automatisch einbinden könnte.
Die bisherigen Punkte würde ich mir zutrauen, aber ein Hybrid-GC ginge über meine Fähigkeiten hinaus.

[himitsu]

Zitat:

Zitat von Medium (Beitrag 1145550)

Mit etwas Unterstützung in der IDE (anderes Highlighting für GC'ed Instanzvariablen) wäre so ein Hybrid glaube ich sogar einigermaßen handlich.

Wenn du jetzt noch sicherstellst, daß es nirgendwo "Altprogramme" gibt, wo z.B. "new" als Variable/Typ/Konstante/Parameter/Feld/... existiert, dann wäre das möglich. :stupid:

Ansonsten hast du ein Problem, da plötzlich aus Diesem ein "reserviertes" Wort werden würde.
In Delphi also nicht möglich, obwohl es auch ohne GC technisch möglich wäre, wenn man den "new"-Operator auf die ".Create"-Constructoren umleitet.


Wenn man Klassen direkt als Interface markieren könnte, bei deren Deklaration, ohne vorher einen extra Interface-Typen manuell deklarieren zu müssen (der Compiler würde dann aus den Public/Published-Dingen dass Interface automatisch generieren), dann hätte man quasi auch einen GC für diese Objekte.
(über die Technik der Generics eventuell machbar, also wenn Emba das implementiert)

Über einen Precompiler könnte ich sowas auch selber nachrüsten. :stupid:

[implementation]

Mich würde jetzt auch mal genauer interessieren, was ihr von der Unit-Umstellung von Interface/Implementation auf Public/Private/Implementation haltet. Stimmt ihr mir zu oder haltet ihr das für überflüssig?
Was haltet ihr von der Methodengruppierung?

[Lemmy]

Zitat:

Zitat von implementation (Beitrag 1145567)

Mich würde jetzt auch mal genauer interessieren, was ihr von der Unit-Umstellung von Interface/Implementation auf Public/Private/Implementation haltet.

Nichts, zum einen weil Public/Private im OOP Bereich schlicht standard ist und es meiner Meinung nach wenig bringt hier Namen zu ändern - das auf was Du raus willst kannst Du auch mit Interface/Implementation machen (oder ich habe es nicht verstanden ;-) )

Zitat:

Zitat von implementation (Beitrag 1145567)

Was haltet ihr von der Methodengruppierung?

was sind für dich Methoden? Was sind für dich "nichtmethodische Routinen"? Und wie soll die Methodengruppierung aussehen? Oder habe ich da auch was nicht verstanden / übersehen?

Grüße

[himitsu]

Im Prinzip eigentlich nicht notwendig.

Interface = Public
Implementation = Private

Protected gibt's da nicht, bzw. es ist sinnlos, da die Vererbung fehlt und es somit dem Private entspricht.

Das Property ohne Klasse könnte nett sein, für globale Variablen oder Singletons.
Aber da man solche Globalen sowieso besser vermeiden sollte, bringt es eigentlich nicht viel.

Die Methodengruppierung finde ich unübersichtlich.

Seh ich irgendwo in der Implementation ein

Delphi-Quellcode:

procedure irgendwas;

, dann denke ich das wäre eine Prozedur und nicht daß sich da irgendwo noch ein

Delphi-Quellcode:

begin

verstecken könnte, welches dieses zu einer Methode macht.
Zwei Klassen, mit einer gleichnamigen Methode, dann stehen unten zwei Prozeduren, welche man nicht direkt einer der Klassen zuordnen kann, ohne vorher nach einem "begin" zu suchen, um zu sehn ob und wenn ja zu welcher Klasse es gehört.

[implementation]

Zitat:

Zitat von Lemmy (Beitrag 1145573)

Nichts, zum einen weil Public/Private im OOP Bereich schlicht standard ist und es meiner Meinung nach wenig bringt hier Namen zu ändern - das auf was Du raus willst kannst Du auch mit Interface/Implementation machen (oder ich habe es nicht verstanden ;-) )

Der Punkt ist, dass momentan unitprivate Deklarationen alle im implementation-Teil liegen, wo dann Deklarationen und Implementierungen querbeet gemischt sind. In meinem Modell geht es darum, im implementation-Teil möglichst auch nur die implementation zu haben. Nicht exportierte Typen, Konstanten und Variablen kommen dann in den private-Teil. Die Reihenfolge der private- und public-Abschnitte ist nicht festgelegt, und es kann auch mehrere geben, um bspw. Global Properties zu ermöglichen, ohne den Getter/Setter auch veröffentlichen zu müssen.

Zitat:

was sind für dich Methoden? Was sind für dich "nichtmethodische Routinen"? Und wie soll die Methodengruppierung aussehen? Oder habe ich da auch was nicht verstanden / übersehen?

Methoden = Prozeduren und Funktionen von Klassen (und erweiterten Records)
nichtmethodische Routinen = Prozeduren und Funktionen, die keiner Klasse angehören

Delphi-Quellcode:

procedure TXyz.DoSmthng; // Methode
function IntToStr(AValue: Integer): string; // keine Methode

Wie die Gruppierung aussehen soll, steht nicht fest (wie allgemein noch nichts), im Entwurf im oberen Post sah sie so aus:

Delphi-Quellcode:

implementation

  TXyz: begin
    
    procedure Xyz;
    begin
      // Do something
    end;

  end;

end.

Zitat:

Zitat von himitsu (Beitrag 1145575)

Im Prinzip eigentlich nicht notwendig.

Interface = Public
Implementation = Private

Da stört es mich aber, dass der implementation-Teil zugleich für unitprivate-Deklarationen und Implementierungen gleichzeitig benutzt wird. Schöner fände ich es, wenn man das trennen würde und im implementation-Teil keine Deklarationen mehr zugelassen würden.

Zitat:

Die Methodengruppierung finde ich unübersichtlich.

Seh ich irgendwo in der Implementation ein

Delphi-Quellcode:

procedure irgendwas;

, dann denke ich das wäre eine Prozedur und nicht daß sich da irgendwo noch ein

Delphi-Quellcode:

begin

verstecken könnte, welches dieses zu einer Methode macht.
Zwei Klassen, mit einer gleichnamigen Methode, dann stehen unten zwei Prozeduren, welche man nicht direkt einer der Klassen zuordnen kann, ohne vorher nach einem "begin" zu suchen, um zu sehn ob und wenn ja zu welcher Klasse es gehört.

Das stimmt natürlich, da ist sie kontraproduktiv. Schön wäre es, irgendwie eine Syntax zu finden, die dieses Problem nicht hat, aber das dürfte schwierig werden.

Zitat:

Aber da man solche Globalen sowieso besser vermeiden sollte, bringt es eigentlich nicht viel.

Stimmt durchaus, vllt. fliegen die Global Properties doch noch ausm Entwurf raus.

[Namenloser]

Zitat:

Zitat von Medium (Beitrag 1145550)

Vielleicht sogar als alternativer Konstruktor, ggf. mit Einführung des new-Operators!

Delphi-Quellcode:

  bar := TMyFooClass.Create(); // <- normal ohne GC
  bar := new TMyFooClass(); // <- GC'ed

Bitte kein new-Operator!
Dieser Operator ist ein Makel, den fast alle Sprachen von C erben. Ich finde es semantisch viel schöner, wenn der Konstruktor wie eine klassenstatische Methode ist, die eine Instanz zurückliefert. Die Klasse selbst ist für die Erzeugung ihrer Instanzen zuständig. Ist das nicht wunderschön OO? :love:

[Medium]

Von mir aus dann eben TMyClass.CreateManaged() oooder in TObject bereits einen Parameter einführen: TObject.Create(isManaged: Boolean); :P
Letztlich gehopst wie gesprungen, wobei ich die syntaktische Unschönheit von new nachfühlen kann. Die Alternative mit Parameter oder Benamung hätte nur ggf. den Nachteil, dass man die Eindeutigkeit in Ableitungen sehr leicht (und fahrlässig) verschleiern könnte, und man es der IDE beim Unterscheiden zusätzlich schwer machen würde. (Sie müsste schon regelrechte Interpreterfähigkeiten bekommen, aber vielleicht wäre das ja mal ein Anreiz die IDE-Features mehr an den Compiler zu knurpseln als z.B. das dolle ErrorInsight oder wie sich die vielen falschen roten Unterwellungen schimpfen, die scheinbar eher selten Plan von der Projektstruktur haben.)

Oder, wobei ich das so garnicht mag: Annotations. Wobei diese dann in die Klassendeklaration gehörten, und somit die GC-Bindung nur per Klasse (und all ihrer Nachfahren) gegeben wäre, und man nicht die Freiheit hätte von Instanz zu Instanz zu unterscheiden. Eher bäh.

[himitsu]

Drum meinte ich ja, im Falle von

Delphi-Quellcode:

bar := new TMyFooClass();

würde der Compiler dann Standard-Constructor "Create" aufrufen, sich einen Suchen, welche den übergebenen Parametern entspricht, falls es diesen gibt und am Ende es zu einem

Delphi-Quellcode:

bar := TMyFooClass.Create();

umwandeln.
Und schon wäre das OOP-Prinzip gewahrt.

Nur wird es eben schwer einen neues "reserviertes Wort" einzuführen.
Das ist wohl auch der Grund, warum es "Class Helper" und nicht nur "Helper" heißt, da durch das reservierte "Class" das Helper geschützt/eingeleitet wird, womit die Syntax dennoch kompatibel bleibt.


Wenn man eine Syntax von Grund auf neu baut, könnte man z.B. NEW gleich reservieren.
Mit den großen Neuerungen und vielen Änderungen seitens D2009/XE2 hätte man diesbezüglich schnell noch ein paar neue "reservierte" Wörter mit einführen und alte Makel in der Syntax ausbessern können.
Wenn sowieso genug angepaßt werden muß, dann kommt es auf die paar Änderungen auch nicht mehr an. :twisted:


Sowas wäre syntaktisch möglich:

Delphi-Quellcode:

type 
  TMyClass = class managed(Txyz)
  end;

genauso wie ja auch sowas gehn:

Delphi-Quellcode:

type
  TMyClass = class sealed(Txyz)
  end; 

  TMyClass = class abstract(Txyz)
  end;

[JamesTKirk]

So... es wird Zeit, dass ich mich auch mal in diese Diskussion einmische. :mrgreen:

Zitat:

Zitat von implementation (Beitrag 1145448)

• Es muss eine strikte Reihenfolge von interface->implementation eingehalten werden. Das heißt, ich kann keine globale Eigenschaft deklarieren, die auf eine private Variable zurückgreift.

Diese Reihenfolge ist einerseits der Tatsache geschuldet, dass Pascal auf Single-Pass-Kompilierung ausgelegt ist (das heißt keine Nutzung darf vor der Deklaration erfolgen (mit wenigen Ausnahmen ala

Delphi-Quellcode:

forward

oder Pointer auf Records)), anderseits arbeiten "Unit basierte" Compiler wie FPC und Delphi so, dass sie sich beim Kompilieren einer weiteren Unit erst nur den Interface Teil der Unit anschauen müssen, um festzustellen, ob sich was geändert hat und demnach die erste Unit neukompiliert werden muss. Wenn du nun Teile des Implementationbereichs in den Interfacebereich schiebst, so muss der Compiler auch über diese Teile hinweg parsen, selbst wenn er sie eventuell gar nicht benötigt, weil sich nichts geändert hat.

Ganz davon abgesehen ist das mit Interface und Implementation Anfängern einfacher zu erklären als "also wenn du da jetzt noch auf eine private Variable der Unit zugreifen möchtest, dann musst du vor diesem Public Abschnitt noch einen Private Abschnitt einfügen"

Zitat:

Zitat von implementation

• Interfaces sind per se immer an Referenzzählung und COM-Kompatibilität gebunden. In meinem halbjährigen Ausflug nach C# habe ich erfahren, wie schön es sein kann, a) in Interfaces für Properties nicht gleich eine Getter/Setter-Methode angeben zu müssen, sondern dies der Implementierung zu überlassen, b) Objekt- und Interfacereferenzen mischen zu können

Kann es sein, dass du hier eher (a), (b) und (c) brauchst? Mit (a) also Hinweis auf Referenzzählung und COM...

Nichtsdestotrotz: Free Pascal unterstützt nicht-referenzgezählte Interfaces (so genannte CORBA Interfaces). Die kannst du (per Unit oder eventuell sogar lokal per Deklaration, das weiß ich grade nicht) ganz einfach per "{$interfaces corba}" aktivieren. Du deklarierst dann ganz einfach dein Interface, diese leiten dann jedoch NICHT von IInterface/IUnknown ab (um genau zu sein haben die dann gar keinen Vorfahrn) und benötigen auch keine Implementierungen für QueryInterface, AddRef und Release. Seit FPC 2.4.0 funktionieren die sogar ähnlich wie COM Interfaces hinsichtlich "as" und so (aber eben ohne Referenzzählung).

Zu deinem a): Dies wäre ein Feature, dem ich eventuell sogar eine gewisse Sinnhaftigkeit zugestehen könnte (ich arbeite nur selten mit Interfaces, deswegen...). Solche Interfaces kannst du dann natürlich nur in Pascal Code einsetzen, da zum Beispiel ein C++ Code, welcher dieses Interface verwendet, nicht wissen kann wie er auf die Property zugreift (außer man streut hier sehr viel Compilermagic ein...)

Zu deinem b): Das Problem hierbei ist die Referenzzählung. Delphi und FPC fügen nur Code zum Ändern der Referenzzählung ein, wenn es sich um eine Interface Referenz handelt. Also rein prinzipiell könntest du sie sogar mischen, wenn du manuell mit AddRef und Release auf der Objektreferenz arbeitest... (nicht dass das unbedingt das sinnvollste ist, aber es würde gehen) Falls du dich jedoch darauf beziehst, dass du einer Objektreferenz keine Interfacereferenz zuweisen kannst, dann hat das den Hintergrund, dass ein Interface ja von unterschiedlichen Klassen implementiert werden kann. Diese Klassen müssen dabei ja nichteinmal verwandt sein. Also eine automatische Konvertierung würde ich da gar nicht wollen. AFAIK unterstützen jedoch modernere Delphi Versionen (XE+?) ein "as", um von Interfaces auf Objekte zu casten und wenn das nicht geht wird eine Exception geworfen (wie von "as" gewohnt). Vielleicht gibt es da auch ein "is", das weiß ich gerade nicht. Das wären auf jeden Fall zwei Features, die zu FPC hinzugefügt werden könnten/sollten.

Zitat:

Zitat von implementation

• Methoden und nichtmethodische Routinen sind im implementation-Teil sprachlich nicht gruppiert (höchstens durch Kommentare)

Das hat mich ehrlich gesagt noch nie gestört (und ich finde deinen Vorschlag dazu auch nicht wirklich eine Verbesserung). Dafür hat man ne gute IDE...

[QOUTE][*]Man kann zwar mehrere verschiedene benannte Destruktoren deklarieren, das hilft aber nichts, weil Free immer nur einen ganz bestimmten aufruft. Wozu haben wir denn unser schönes Benennungsfeature?[/LIST]
Und es funktioniert auch wie es soll. "Free" ist nur eine normale Prozedur deren einziger Sinn es ist zu überprüfen, ob "Self <> Nil" ist und dann den Default-Destruktor "Destroy" aufruft. Nichts hält mich davon ab einen Destruktor mit einem anderen Namen zu definieren und einfach direkt aufzurufen. Es ist nämlich der Aufruf des Destruktors, der die Speicherfreigabe veranlasst, nicht der von Free (sonst bräuchten wir ja kein spezielles Keyword für den Destruktor).

Delphi-Quellcode:

  type
    // Schema-Typ, wie in GPC:
    TCharArray(start, length: Integer) = array [start..start+length] of char;
    TSample = TCharArray(0,6);

Schematypen stehen bei mindestens einem FPC-Entwickler auf der Wunschliste.

Weil's grad zum Kontext passt noch der Einwurf Himitsus dazu:

Zitat:

Zitat von himitsu (Beitrag 1145518)

Delphi-Quellcode:

TCharArray(start, length: Integer) = array [start..start+length] of char;
TSample = TCharArray(0,6);

Sieht einfach nur häßlich aus und paßt nicht zur Pascal/Delphi-Syntax.

Im Gegensatz zu vielen der Features die uns lieb sind wie Klassen, Generics, etc. sind Schematypen sogar Teil des ISO-Standards.

Zitat:

Zitat von himitsu

- die Generics so erweitern, daß man statt typen auch Konstanten verwenden kann.
(würde dann teilweise ähnliche Möglichkeiten bieten, wie die Makros in C)

Ich weiß nicht, ob das wirklich so gut wäre... es wäre schon schwierig sowas zu parsen:

Delphi-Quellcode:

type
  TTest<const c> = class

  end;

var
  TTest: Integer; // was ja erlaubt ist in Delphi! (in FPC funktioniert das noch nicht...)

begin
  if TTest<5>.Irgendwas then 
    ...
end.

Der Compiler muss den Punkt "TTest<5" nun irgendwie intelligent behandeln. Es kann vielleicht schaffbar sein, aber wenn ich mir allein den Code anschau, den ich geschrieben habe, um die Inlinespezialisierung "TTest<SomeType>" zu erlauben, dann möchte ich nicht wissen, was ich da alles verbrechen muss (und dabei hab ich es noch nichteinmal geschafft die Überladung mit einer Variable zu implementieren, das steht noch auf meiner ToDo Liste, weil's (hoffentlich) ein extremes Randbeispiel ist).

Zitat:

Zitat von himitsu

- ein mehrstufiger Compiler, bzw. ein intelligenterer, so daß man besseren Zugriff auf die Typen hat, welche im denerischen Type enthalten sind.

Kannst du das bitte genauer erklären?

Zitat:

- generische Prozeduren, Interfaces und Class Helper (nicht nur Klassen.Methoden)

Generische Prozeduren werde ich auf jeden Fall mitimplementieren, wenn ich generische Methoden implementiere. Aber Interfaces kann man doch bereits generisch deklarieren, oder verpeile ich da was? Generische Class Helper könntest du übrigens nur in der folgenden Form nutzen, da du beim Aufruf einer Class Helper Methode ja keinen Typen angeben kannst:

Delphi-Quellcode:

type
  TSomeClassHelper<T> = class helper for TObject
    function ReturnDefault: T; // mir fällt grad nichts besseres ein
  end;

function TSomeClassHelper.ReturnDefault;
begin
  Result := Default(T);
end;

type
  TSomeClassHelperInteger = TSomeClassHelper<Integer>;

var
  i: Integer;
...
  i := SomeObject.ReturnDefault;
...

Zitat:

Zitat von himitsu

- Class Helper Record Helper für einfache Basistypen, wie t.B. den Integer oder den String

- Interface Helper

Du wirst lachen... seitdem ich record und class helper in FPC implementiert habe, denke ich immer wieder darüber nach die auf interfaces, objects und eventuell auch primitive Typen zu erweitern (als FPC-Entwickler darf man die objects nicht vernachlässigen ;) ). Die ersteren beiden sollten vergleichsweise einfach zu implementieren sein (nur bei Interfaces müsste ich aufpassen, dass mir die Referenzzählung keinen Strich durch die Rechnung macht). Primitive Typen würde wohl einige Anpassungen des Parsers nach sich ziehen...

Zitat:

Zitat von himitsu

- Operatoren für Interfaces

In FPC kannst du diese bereits deklarieren (zwar nicht innerhalb von Interfaces, aber es sollte gehen :) ).

Zitat:

Zitat von himitsu

- Operatoren für Copy, Create und Destroy von Records
(technisch leicht möglich, da alle Struckturen schon existieren ... siehe Behandlung der Interfaces, dyn. Arrays und der Strings innerhalb von Records)

Was möchtest du da genau? Hättest du da vielleicht ein Beispiel?

Zitat:

Zitat von himitsu

- endlich mal ein Versesserung einiger Grenzen in der OTA
(jbg bekommt auch immer wieder mit, daß Vieles einfach nur fehlt oder schecklich implementiert ist)

- und ein OTA-Interface für einen eigenen Precompiler

Was heißt OTA?

Zitat:

Zitat von himitsu

- daß man bei dyn. Arrays das CopyOnWrite aktivieren kann, so wie es bei den Strings auch vorhanden ist

AFAIK unterstützt FPC dies auch bereits.

Zitat:

Zitat von himitsu

- absolute mit einer Typsicherheits- und Größenprüfung (Compilerwarnung)

Solange diese Compilerwarung ein Opt-In ist...

Zitat:

Zitat von himitsu

- string aus den reservierten Wörtern rausnehmen

Es sieht zwar nicht so schön aus, aber ein

Delphi-Quellcode:

&String

sollte es doch tun, oder nicht?

Zitat:

Zitat von himitsu

- ein "caseend" für die varianten Recordteile ("end" geht ja nicht mehr ... das hätte man gleich zu Beginn nicht vergessen dürfen :wall:)

Ich glaub "vergessen" ist das falsche Wort. Das wurde damals wahrscheinlich absichtlich so gemacht. Die Begründung könnte vielleicht sein, dass man sich nicht mit einem Case inmitten eines Records herumschlagen wollte (hinsichtlich Memory-Layout).

Zitat:

Zitat von himitsu

- das Strg+Linksklick auf einen generischen Teil (Methode,Feld,...) nicht bei "implementation" landet, sondern beim generischen Typen :roll:

Ehm... was hat das mit der Sprachsyntax zu tun? Das ist ein Problem der IDE...

Zitat:

Zitat von NamenLozer (Beitrag 1145507)

• Ich finde, man sollte Variablen immer bei der Deklaration initialisieren können, also nicht nur globale Variablen, sondern auch Felder und lokale Variablen.
  Delphi-Quellcode:

  var x: integer = 0

Zumindest das mit lokalen Variablen kann Free Pascal zum Beispiel. Für Felder geht das nicht.

Zitat:

Zitat von NamenLozer

• Oft nervt mich die Operatoren-Priorität bei Konditionalen – dass man um Vergleiche immer eine Klammer setzen muss, wenn man sie per AND oder OR verknüpfen will. Ich kenne keine andere Sprache, wo das so ist.
  Delphi-Quellcode:

  if a<b and b<c then ...

  statt
  Delphi-Quellcode:

  if (a<b) and (b<c) then ...

  . Wann will man schon mal tatsächlich zwei Werte in einer Abfrage binär verknüpfen? Außerdem wäre das ja immer noch möglich, eben mit Klammerung. Ich wünschte mir hier einfach ein anderes Default.

Das große Problem bei solchen Änderungen ist die Abwärtskompatibilität. Sowas sollte als nur per Compilerschalter möglich sein. Ansonsten schließe ich mich hier im Sinne von "in" an:

Delphi-Quellcode:

if not (SomeEnum in SomeSet) then
// vs
if not SomeEnum in SomeSet then

Dass ich da Klammern setzen muss, hat mich schon immer aufgeregt...

Zitat:

Zitat von NamenLozer

• Ich fände es außerdem cool, wenn sowas ginge:
  Delphi-Quellcode:

  if a < b < c then ...

  . Ich glaube Prism/Oxygene kann das.

Waaahhhh!!! Bloß nicht! Meine ganze Logik für

Delphi-Quellcode:

if TSomeGeneric<SomeType>.BlaBla

fusst darauf, dass genau das eben nicht geht!

Zitat:

Zitat von NamenLozer

• Hin und wieder nervt mich, dass man im Interface-Bereich Felder immer vor Methoden deklarieren muss.

FPC konnte das früher mal, das wurde jedoch abgeschafft. Begründung siehe hier

Zitat:

Zitat von NamenLozer

• Delphi-Quellcode:

  try ... except ... finally ... end

  statt zwei try-Blöcke schachteln zu müssen.

Ja, manchmal wäre das durchaus schön (vor allem, wenn man ein paar mehr von den Viechern geschachtelt hat...)

Zitat:

Zitat von Medium (Beitrag 1145550)

Mein Wunsch geht zwar über Syntax hinaus, und dafür würden mich sicher hier gerne einige vermöbeln, aber ein Delphi mit GC wäre schon sexy. Ich weiss, es gibt da diverse Fummelein mit Interfaces und Hacks, aber ein richtiger "ab Werk" GC ist einfach eine riesen Komfortsteigerung (wenn er vernünftig umgesetzt ist). Was ich in C# ab und an gern mache, und in Delphi ab und an wünschte, ist sowas wie

Delphi-Quellcode:

lokaleVarMitRückgabewert := TMyFooClass.Create(aParameter).SomeMethod(aNotherParameter);

, und die Instanz dann einfach verpuffen lassen. (Ja, das sieht nach einem Designfehler aus, man meint die Methode hätte statisch sein sollen - aber so schlau sind leider nicht alle Fremdkomponentenhersteller.) Oder auch so Späße, bei denen Instanzen über mehrere Threads eher "locker umher geworfen" werden würden mit einem GC etwas weniger Kopfschmerzlastig.

Vielleicht sogar als alternativer Konstruktor, ggf. mit Einführung des new-Operators!

Delphi-Quellcode:

  bar := TMyFooClass.Create(); // <- normal ohne GC
  bar := new TMyFooClass(); // <- GC'ed

Mit etwas Unterstützung in der IDE (anderes Highlighting für GC'ed Instanzvariablen) wäre so ein Hybrid glaube ich sogar einigermaßen handlich.

Vielleicht weniger über einen neuen Konstruktor gehen, als die Variablendeklaration zu ändern:

Delphi-Quellcode:

var
  bar: TMyFooClass autoref;
begin
  bar := TMyFooClass.Create;
  ...
  // bar wird automatisch freigegeben, falls keine Referenz darauf mehr existiert (die Überprüfung hierzu ist jedoch schwierig)
end;

Wie gut das funktionieren würde, wenn man Objekte über Prozeduren hinweg reicht, weiß ich noch nicht, aber es wäre vielleicht eine Idee...

Zitat:

Zitat von himitsu

Wenn man Klassen direkt als Interface markieren könnte, bei deren Deklaration, ohne vorher einen extra Interface-Typen manuell deklarieren zu müssen (der Compiler würde dann aus den Public/Published-Dingen dass Interface automatisch generieren), dann hätte man quasi auch einen GC für diese Objekte.
(über die Technik der Generics eventuell machbar, also wenn Emba das implementiert)

Hmm... vielleicht sowas:

Delphi-Quellcode:

type
  TSomeRefCountedObject = class refcounted (TParentClass) // in dieser Reihenfolge, um analog zu "sealed" und "abstract" zu sein

  end;

Zitat:

Zitat von himitsu (Beitrag 1145535)

Zitat:

Zitat von implementation (Beitrag 1145530)

Wäre es nicht schön, einfach ein Helperkonstrukt für alle Typen zu haben, statt zwischen Class-, Record und Interface-Helpern zu unterscheiden?

Im Prinzip hast du ja Recht, denn über den Zieltüben ließe es sich ja unterscheiden.
Aber dann wäre es nicht mehr ganz kompatibel zum alten Code.

Wieso? "class helper" und "record helper" könnte für alten Code ja bestehen bleiben. Ansonsten (auch für Klassen und Records) ist einfach nur "helper for" möglich.

Und was ich mir wünsche (und vielleicht auch mal implementieren werde):

• Mehrere Class/Record Helper können für einen Typen gleichzeitig verfügbar sein (müsste vergleichsweise einfach für mich umzusetzen sein, da der Code bereits entsprechend ausgelegt ist :mrgreen: )

So... Ende der langen Liste :P

Gruß,
Sven

[implementation]

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Diese Reihenfolge ist einerseits der Tatsache geschuldet, dass Pascal auf Single-Pass-Kompilierung ausgelegt ist (das heißt keine Nutzung darf vor der Deklaration erfolgen (mit wenigen Ausnahmen ala

Delphi-Quellcode:

forward

oder Pointer auf Records)), anderseits arbeiten "Unit basierte" Compiler wie FPC und Delphi so, dass sie sich beim Kompilieren einer weiteren Unit erst nur den Interface Teil der Unit anschauen müssen, um festzustellen, ob sich was geändert hat und demnach die erste Unit neukompiliert werden muss. Wenn du nun Teile des Implementationbereichs in den Interfacebereich schiebst, so muss der Compiler auch über diese Teile hinweg parsen, selbst wenn er sie eventuell gar nicht benötigt, weil sich nichts geändert hat.

Am Interface-Teil will ich ja an sich auch nichts ändern, sondern fände es schön, den implementation-Teil aufzusplitten in Deklarationen und die tatsächliche Implementierung. Und wenn der public-Teil am Anfang der Unit steht, muss der Compiler ja auch über nichts überflüssiges hinwegparsen.

Zitat:

Ganz davon abgesehen ist das mit Interface und Implementation Anfängern einfacher zu erklären als "also wenn du da jetzt noch auf eine private Variable der Unit zugreifen möchtest, dann musst du vor diesem Public Abschnitt noch einen Private Abschnitt einfügen"

Das mag ich bezweifeln, denn so kann man jetzt sagen: "Das machst du dann wie bei Klassen, du schreibst öffentliches in den public- und privates in den private-Teil"

Zitat:

Nichtsdestotrotz: Free Pascal unterstützt nicht-referenzgezählte Interfaces (so genannte CORBA Interfaces). Die kannst du (per Unit oder eventuell sogar lokal per Deklaration, das weiß ich grade nicht) ganz einfach per "{$interfaces corba}" aktivieren.

Wenn dies tatsächlich per Deklaration geht, wäre das sehr praktisch. Dennoch fände ich es deutlich schöner, diese mit einem Schlüsselwort zu unterscheiden, da sie von ganz anderer Natur sind.

Zitat:

Zu deinem b): Das Problem hierbei ist die Referenzzählung. Delphi und FPC fügen nur Code zum Ändern der Referenzzählung ein, wenn es sich um eine Interface Referenz handelt. Also rein prinzipiell könntest du sie sogar mischen, wenn du manuell mit AddRef und Release auf der Objektreferenz arbeitest... (nicht dass das unbedingt das sinnvollste ist, aber es würde gehen)

Wo das Problem liegt, ist mir durchaus bewusst, deshalb möchte ich an der Stelle ja Interfaces ohne Zählung, die ich dann genauso anwenden kann wie in C#. Jedesmal AddRef und Release ist mir dann doch zu nervig. Die Idee der Interfaces ist eine tolle Sache, aber wir können sie so einfach nicht voll nutzen.

Zitat:

Das hat mich ehrlich gesagt noch nie gestört

Mich auch nicht, das war eher ein Spontaneinfall während des Entwurfsschreibens :stupid:

Zitat:

(und ich finde deinen Vorschlag dazu auch nicht wirklich eine Verbesserung)

Ich auch nicht. :lol:

Zitat:

Und es funktioniert auch wie es soll. "Free" ist nur eine normale Prozedur deren einziger Sinn es ist zu überprüfen, ob "Self <> Nil" ist und dann den Default-Destruktor "Destroy" aufruft. Nichts hält mich davon ab einen Destruktor mit einem anderen Namen zu definieren und einfach direkt aufzurufen. Es ist nämlich der Aufruf des Destruktors, der die Speicherfreigabe veranlasst, nicht der von Free (sonst bräuchten wir ja kein spezielles Keyword für den Destruktor).

Schöner wäre es aber, wenn der Destruktor das selbst überprüfen würde, dann bräuchten wir eben diese Methode Free nicht.

Zitat:

Zitat:

Zitat von himitsu

- die Generics so erweitern, daß man statt typen auch Konstanten verwenden kann.
(würde dann teilweise ähnliche Möglichkeiten bieten, wie die Makros in C)

Ich weiß nicht, ob das wirklich so gut wäre... es wäre schon schwierig sowas zu parsen:

Letztendlich wäre das ja nichts groß anderes, als die Schemata. Man müsste das nur syntaktisch ein bisschen austüfteln.

[JamesTKirk]

Zitat:

Zitat von implementation (Beitrag 1145648)

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Diese Reihenfolge ist einerseits der Tatsache geschuldet, dass Pascal auf Single-Pass-Kompilierung ausgelegt ist (das heißt keine Nutzung darf vor der Deklaration erfolgen (mit wenigen Ausnahmen ala

Delphi-Quellcode:

forward

oder Pointer auf Records)), anderseits arbeiten "Unit basierte" Compiler wie FPC und Delphi so, dass sie sich beim Kompilieren einer weiteren Unit erst nur den Interface Teil der Unit anschauen müssen, um festzustellen, ob sich was geändert hat und demnach die erste Unit neukompiliert werden muss. Wenn du nun Teile des Implementationbereichs in den Interfacebereich schiebst, so muss der Compiler auch über diese Teile hinweg parsen, selbst wenn er sie eventuell gar nicht benötigt, weil sich nichts geändert hat.

Am Interface-Teil will ich ja an sich auch nichts ändern, sondern fände es schön, den implementation-Teil aufzusplitten in Deklarationen und die tatsächliche Implementierung. Und wenn der public-Teil am Anfang der Unit steht, muss der Compiler ja auch über nichts überflüssiges hinwegparsen.

Wenn man sich aber deine Anmerkung bzgl. globalen Properties ansieht (welche, @restliche DP in FPC übrigens verfügbar sind), dann müsste dort mindestens ein "private" Abschnitt vor einem "public" Abschnitt kommen und du hast den Salat wieder.

Zitat:

Zitat von implementation

Zitat:

Nichtsdestotrotz: Free Pascal unterstützt nicht-referenzgezählte Interfaces (so genannte CORBA Interfaces). Die kannst du (per Unit oder eventuell sogar lokal per Deklaration, das weiß ich grade nicht) ganz einfach per "{$interfaces corba}" aktivieren.

Wenn dies tatsächlich per Deklaration geht, wäre das sehr praktisch. Dennoch fände ich es deutlich schöner, diese mit einem Schlüsselwort zu unterscheiden, da sie von ganz anderer Natur sind.

Ich hab mal schnell getestet: es ist wirklich eine lokale Option (wie {$M+/-}).

Zitat:

Zitat von implementation

Zitat:

Und es funktioniert auch wie es soll. "Free" ist nur eine normale Prozedur deren einziger Sinn es ist zu überprüfen, ob "Self <> Nil" ist und dann den Default-Destruktor "Destroy" aufruft. Nichts hält mich davon ab einen Destruktor mit einem anderen Namen zu definieren und einfach direkt aufzurufen. Es ist nämlich der Aufruf des Destruktors, der die Speicherfreigabe veranlasst, nicht der von Free (sonst bräuchten wir ja kein spezielles Keyword für den Destruktor).

Schöner wäre es aber, wenn der Destruktor das selbst überprüfen würde, dann bräuchten wir eben diese Methode Free nicht.

Es wäre interessant die Begründung von Borland zu hören, warum sie sich damals dafür entschieden haben, dass "Destroy" das nicht überprüft...

Zitat:

Zitat von implementation

Zitat:

Zitat:

Zitat von himitsu

- die Generics so erweitern, daß man statt typen auch Konstanten verwenden kann.
(würde dann teilweise ähnliche Möglichkeiten bieten, wie die Makros in C)

Ich weiß nicht, ob das wirklich so gut wäre... es wäre schon schwierig sowas zu parsen:

Letztendlich wäre das ja nichts groß anderes, als die Schemata. Man müsste das nur syntaktisch ein bisschen austüfteln.

Die Einführung der Schemata wäre wahrscheinlich einfacher als sowas. "<" ist einfach zu sehr belastet... :(

Gruß,
Sven

[DP-Maintenance]

Dieses Thema wurde am "12. Jan 2012, 17:07 Uhr" von "TBx" aus dem Forum "Programmieren allgemein" in das Forum "Software-Projekte der Mitglieder" verschoben.

[himitsu]

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Delphi-Quellcode:

if not (SomeEnum in SomeSet) then
// vs
if not SomeEnum in SomeSet then

NOT ist nunmal höherrangig, als IN, da führt kein drumrum.

Auch wenn man jetzt das IN vorrangig behandeln würde, wäre das keine Lösung, da sich dann Andere wieder beschweren würden, weil plötzlich was Anderes nicht mehr ginge.

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Es sieht zwar nicht so schön aus, aber ein

Delphi-Quellcode:

&String

sollte es doch tun, oder nicht

genau, voll häßlich.

Ich weiß nichtmal, warum man STRING so behandeln mußte?
Und wenn, warum ist dann Integer, Boolean und Co. nicht auch fett? :gruebel:

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Was heißt OTA?

Open Tools API ... die Schnittstelle zur IDE

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Was möchtest du da genau? Hättest du da vielleicht ein Beispiel?

(angenommen dort sind bestimmte Typen im Record, wie z.B. Strings, dyn. Array oder Interfaces)

Delphi-Quellcode:

var
  X, Y: TMyRecord;
begin  << X und Y werden initialisiert (wenn dort bestimmte Typen drauf sind)

Y := X;  << es wird eine Kopierfunktion aufgerufen, welche den Record kopiert

end;  << es wird eine Funktion aufgerufen, welche den Record freigibt

In diesen schon vorhandenen Funktionen muß man nur noch schauen, ob in der RTTI des Records die neuen Operatoren stehen und ruft sie dann auf.
Es gibt schon seit langem einen EDN.Eintrag von mir, aber auf mich hört ja keiner. (vorallem da es keine großen Änderungen mit sich zieht)

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1145711)

Auch wenn man jetzt das IN vorrangig behandeln würde, wäre das keine Lösung, da sich dann Andere wieder beschweren würden, weil plötzlich was Anderes nicht mehr ginge.

Das ganze Problem kommt daher, das die booleschen und die bitweisen Operatoren gleich heißen.
Die Bitweisen möchte man halt gerne stark binden und die Booleschen schwach.

Intuitiv würde ich aber auch eher immer annehmen, das ein boolescher Operator gemeint ist.
Wer mit bitweisen Operatoren werkelt, kann auch ein paar Klammern mehr vertragen :wink:

Oder wie wäre es mit lnot, land, lor :stupid:

[JamesTKirk]

Zitat:

Zitat von himitsu (Beitrag 1145711)

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Delphi-Quellcode:

if not (SomeEnum in SomeSet) then
// vs
if not SomeEnum in SomeSet then

NOT ist nunmal höherrangig, als IN, da führt kein drumrum.

Auch wenn man jetzt das IN vorrangig behandeln würde, wäre das keine Lösung, da sich dann Andere wieder beschweren würden, weil plötzlich was Anderes nicht mehr ginge.

Darum gings doch gerade. NamenLozer hatte geschrieben, dass er gerne sehen würde, dass z.B. ">" stärker bindet als z.B. "and". Und wenn wir da schon dabei sind, dann hätte ich gerne, dass "in" stärker bindet als "not", weil ich mir echt keine wirkliche Situation vorstellen kann, in der "(not SomeEnum) in SomeSet" Sinn hätte... aus Compilersicht ist das was wir aktuell haben vielleicht sogar die einfachere Lösung (also das "not" stärker bindet).

Zitat:

Zitat von himitsu

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Es sieht zwar nicht so schön aus, aber ein

Delphi-Quellcode:

&String

sollte es doch tun, oder nicht

genau, voll häßlich.

Ich weiß nichtmal, warum man STRING so behandeln mußte?
Und wenn, warum ist dann Integer, Boolean und Co. nicht auch fett? :gruebel:

Weil Integer, Boolean und Co. keine Schlüsselwörter sind. Der Compiler würde dich nicht davon abhalten eine eigene Funktion "Integer" zu definieren. String ist wahrscheinlich ein wegen ShortString ein Schlüsselwort:

Delphi-Quellcode:

type
  String42 = String[42];

Zitat:

Zitat von himitsu

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Was heißt OTA?

Open Tools API ... die Schnittstelle zur IDE

Danke.

Zitat:

Zitat von himitsu

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Was möchtest du da genau? Hättest du da vielleicht ein Beispiel?

(angenommen dort sind bestimmte Typen im Record, wie z.B. Strings, dyn. Array oder Interfaces)

Delphi-Quellcode:

var
  X, Y: TMyRecord;
begin  << X und Y werden initialisiert (wenn dort bestimmte Typen drauf sind)

Y := X;  << es wird eine Kopierfunktion aufgerufen, welche den Record kopiert

end;  << es wird eine Funktion aufgerufen, welche den Record freigibt

In diesen schon vorhandenen Funktionen muß man nur noch schauen, ob in der RTTI des Records die neuen Operatoren stehen und ruft sie dann auf.
Es gibt schon seit langem einen EDN.Eintrag von mir, aber auf mich hört ja keiner. (vorallem da es keine großen Änderungen mit sich zieht)

Die Kopierfunktion könnte aber von überladenen Zuweisungsoperatoren beeinflusst werden...
Diese Ereignisse wären aber durchaus interessant, das müsste ich mir mal im FPC anschauen, was man da machen könnte.

Gruß,
Sven

[Namenloser]

Zitat:

Zitat von himitsu

Zitat:

Zitat von JamesTKirk (Beitrag 1145646)

Was möchtest du da genau? Hättest du da vielleicht ein Beispiel?

(angenommen dort sind bestimmte Typen im Record, wie z.B. Strings, dyn. Array oder Interfaces)

Delphi-Quellcode:

var
  X, Y: TMyRecord;
begin  << X und Y werden initialisiert (wenn dort bestimmte Typen drauf sind)

Y := X;  << es wird eine Kopierfunktion aufgerufen, welche den Record kopiert

end;  << es wird eine Funktion aufgerufen, welche den Record freigibt

In diesen schon vorhandenen Funktionen muß man nur noch schauen, ob in der RTTI des Records die neuen Operatoren stehen und ruft sie dann auf.
Es gibt schon seit langem einen EDN.Eintrag von mir, aber auf mich hört ja keiner. (vorallem da es keine großen Änderungen mit sich zieht)

Das hab ich mir auch schon gewünscht. Ich habe mich schonmal mit einem Interface beholfen, das in einem Record verpackt ist. Ist aber ein ziemlicher Hack.

Das traurige ist ja, dass entsprechende Funktionen zum Finalisieren von Records und Arrays ja bereits vorhanden sind – sieht man auch im Assembler-Code. Nur leider gibt es keine Möglichkeit, sich dort einzuklinken.

[himitsu]

Eine Möglichkeit gäbe es.

Die System.pas verändern, neu kompilieren und dann auch noch alle BPLs neu kompilieren.
Statt einem Operator könnte man Klassenmethoden verwenden, welche jeweils einen vorgegebenen Namen und bestimmte Parameter haben müßten.

Aber vorallem das Ändern der System.pas und vorallem der BPLs, ist nicht grade optimal schön.

[implementation]

Zitat:

Zitat von himitsu (Beitrag 1145819)

Die System.pas verändern, neu kompilieren und dann auch noch alle BPLs neu kompilieren.

Ich dachte, die System.pas sei nur ein Dummy und ihre Funktionalität fest im Compiler verankert?

[himitsu]

Hab ich auch gedacht, aber mit ein paar speziellen Parametern (Einstellungen) seitens des Compilers, soll es möglich sein.

Denn Records haben, vorallem im Zusammenhang mit Mathematikbibliotheken, einige Vorteile.

Objekte => garkeine automatische Speicherverwaltung, der Objektvariable
Interfaces => automatische Freigabe, wenn der letzte Weg ist
Records => automatische Speicherreservierung, Freigabe für jede Variable einzeln, Umkopieren bei Variablenzuweisung usw.

[JamesTKirk]

Wahrscheinlich (ich werde für den Delphi Compiler jedoch keine Hand ins Feuer legen) wird diese geänderte System.pas aber nur funktionieren, wenn das Record auch Felder von "managed" Typen wie Strings, Arrays oder Interfaces enthält. Ansonsten wird sich der Compiler wahrscheinlich denken: "och, da muss ich nichts machen, also machen wir ein einfaches "Verringern des Stackpointers" (Speicherplatz belegen), "Move" (Zuweisung), "Erhöhen des Stackpointers" (Speicherfreigabe, wobei das auch meist durch ein "ret" abgedeckt wird).

Für FPC muss ich erst nachschauen, was der bei Records mit "managed" Feldern überhaupt aufruft :)

Ein wichtiger Punkt ist bei diesem Feature jedoch dabei: ein RTTI Lookup für die "Ereignisbehandlungsroutine" ist relativ aufwendig. Wenn dies also bei jedem Record gemacht wird, dann wird es relativ teuer Records zu verwenden (dann muss man fast schon zu den guten, alten Objects greifen, wenn man den Overhead vermeiden möchte :P ).

Gruß,
Sven

[Blup]

Ich hätte gern Mehrfachvererbung für Interfaces:

Delphi-Quellcode:

type
  MyInterface3 = interface(MyInterface1, MyInterface2)
  end;

var
  v1: MyInterface1;
  v2: MyInterface2;
  v3: MyInterface3;
begin
  v1 := v3;
  v2 := v3;

Mehrere Class-Helper sollten sich für eine Klasse nicht gegenseitig ausschließen.

[himitsu]

Jupp, und auch deshalb muß es direkt von Embarcadero implementiert werden, dann dort könnte man diese Optimierung dann anpassen und auch ein ordentlicher Operator wäre dann möglich/vorhanden.


Mehrfachvererbung geht nunmal nicht. Aus dem selben Grund, warum es auch bei Klassen nicht geht.
Bei den "einfachen" Interfaces werden die Methoden über einen Index aufgerufen.
Bei Interface-Vererbung baut das neue Interface auf das alte auf, also es wird weitergezählt und weiterzählen ist nur für einem Vorfahren möglich, bzw. es können keine Indize mehrfach belegt sein, was bei mehrere Vorfahren aber zutreffen würde.


Für gewisse COM-Interfaces, wo die Methoden über einen Namen aufgerufen würden, würde es theoretisch gehen, aber da die Möglichkeit von gleichen Namen bestünde, ist das also unsicher und somit besser ganz ausgeschlossen.

[Blup]

Zitat:

Zitat von himitsu (Beitrag 1145839)

Mehrfachvererbung geht nunmal nicht. Aus dem selben Grund, warum es auch bei Klassen nicht geht.
Bei den "einfachen" Interfaces werden die Methoden über einen Index aufgerufen.
Bei Interface-Vererbung baut das neue Interface auf das alte auf, also es wird weitergezählt und weiterzählen ist nur für einem Vorfahren möglich, bzw. es können keine Indize mehrfach belegt sein, was bei mehrere Vorfahren aber zutreffen würde.

Ich verstehe deine Bedenken, aber gerade bei Interfaces sind nicht unbedingt die selben Einschränkungen wie für Klassen nötig.

Delphi-Quellcode:

type
  TMyClass = class(TObject, MyInterface1, MyInterface2)
  end;

Selbst wenn beide Interfaces auf die selben Methoden verweisen würden, ist dies kein Problem.

Der Compiler müsste für die Realisierung der Mehrfachvererbung bei der Prüfung von Zuweisungen die doppelte Vererbung berücksichtigen und an dieser Stelle ein "QueryInterface" einfügen.

[himitsu]

Das ist aber keine Mehrfachverwebung.

Es wird nur von TObject geerbt.
Die Interfaces werden nur implementiert. Das eine Objekt wird mit mehreren Interfaces verbunden, was natürlich geht, aber wenn man sich einen Interfacezeiger von diesem Objekt holt, dann zeigt der immer nur auf jeweils eines der möglichen Interfaces.

Das hier ist eine Interfacevererbung (ein Interface erbt von einem anderem Interface):

Delphi-Quellcode:

type
  IMyIntertface = interface(IOtherInterface)
    [MyGUID]
    ...
  end;

Objekte erben nur von Objekten und Interfaces nur von Interfaces ... eine Vermischung der Rassen tritt nicht ein.

[Blup]

Ich wollte nur zeigen was bisher möglich ist und wie der Compiler arbeiten müsste, um Mehrfachvererbung zu ermöglichen. Natürlich ist intern eine Sonderbehandlung durch den Compiler notwendig. Im Detail stelle ich mir das ungefähr so vor:

Delphi-Quellcode:

type
  MyInterface1 = interface
    procedure My1;
    procedure MyX;
    procedure MyY;
  end;
  
  MyInterface2 = interface
    procedure My2;
    procedure MyX;
    procedure MyY(AValue: Integer);
  end;

  MyInterface3 = interface(MyInterface1, MyInterface2)
//  Compiler-Magie -> MyInterface3 = interface()
//  automatisch unsichtbar hinzugefügt ->
    procedure My1;                            // aus MyInterface1
    procedure MyX;                            // aus MyInterface1, MyInterface2 -> nur einmal da eindeutig
    procedure MyY; overload;                  // aus MyInterface1, andere Parameter
    procedure My2;                            // aus MyInterface2
    procedure MyY(AValue: Integer); overload; // aus MyInterface2, andere Parameter
//  vom Entwickler neu definiert ->
    procedure MyZ;
  end;

  TMyObject = class(TInterfacedObject, MyInterface3)
//  automatisch durch den Compiler hinzugefügt: MyInterface1, MyInterface2
    procedure My1;
    procedure MyX;
    procedure MyY; overload;
    procedure My2;
    procedure MyY(AValue: Integer); overload;
    procedure MyZ;
  end;

var
  v1: MyInterface1;
  v2: MyInterface2;
  v3: MyInterface3;
begin
  v1 := v3; // Compiler erkennt Mehrfachvererbung ->  v3.QueryInterface(MyInterface1, v1);
  v2 := v3; // Compiler erkennt Mehrfachvererbung ->  v3.QueryInterface(MyInterface2, v2);

[himitsu]

Und das ist bei den normalen/einfachen Interfaces falsch, denn es geht nicht um Methodennamen ... diese sind vollkommen egal.

Delphi-Quellcode:

  MyInterface1 = interface
    procedure My1;  // Methode 1 (Index 0)
    procedure MyX;  // Methode 2 (Index 1)
    procedure MyY;  // Methode 3 (Index 2)
  end;
  
  MyInterface2 = interface
    procedure My2;  // Methode 1 (Index 0)
    procedure MyX;  // Methode 2 (Index 1)
    procedure MyY(AValue: Integer);  // Methode 3 (Index 1)
  end;

Beim Objekt verlinkt der Compiler nun die Interfaces und hinterlegt, bei den Methodenlisten er Interfaces, die Zeiger zu den jeweiligen Methoden.

Will man nun mehrere Interfaces vererben, dann müßten im abgeleiteten Interface nun jeweiles mehere Methoden zu einem Index hinterlegt werden, was natürlich nicht geht.
Auch den Indize verschieben geht nicht, da es dann nicht mehr zum Vorfahren paßt.

Selbst wenn nur die Indize hinereinander gelegt würden, also die Indize des zweiten Interfaces werden verschoben, ohne daß das Vorfahreninterface wirklich "implementiert" würde, also quasi der Vorfahre wird nur als Vorlage verwendet, wäre das keine sichere Methode, denn wenn man den Vorfahren verändert, würde das eigene Interface verändert.