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
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
Zitat:
(und ich finde deinen Vorschlag dazu auch nicht wirklich eine Verbesserung)
Ich auch nicht.
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 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.