TFile, TDirectory vs. alte Funktionen

[bernau]

Ich habe es nun endlich geschafft. Bin von Delphi 2007 auf XE8 umgestiegen. Man schaut dann natürlich nach neuen Klassen, Datenstrukturen etc.

Beim Stöbern durch das Emba-Wiki habe ich folgende Typen gefunden TFile, TPath, TDirectory. Darunter sind etliche nützliche Klassenmethoden vorhanden. Vieles gibt es natürlich schon in der RTL. Z.B. ersetzt Tfile.exists die Funktion fileexists. Ich finde die neue Schreibweise sehr angenehm. So muss ich nur "TFile." eingeben und die Codevervollständigung gibt mir alle Funktionen, die ich mit Dateien machen kann. Seit wann gibt es diese Typen?

Ich denke ich werde die neue Schreibweise übernehmen. Wie findet Ihr diese Schreibweise?

[Der schöne Günther]

Natürlich nur das. Ist ja nicht nur eine andere (ordentliche) "Schreibweise", sondern viel Neues: Dinge wie TDirectory.GetFiles(..) machen das Leben doch gleich unheimlich viel angenehmer 8-)

[Daniel]

Zitat:

Zitat von bernau (Beitrag 1311964)

Ich denke ich werde die neue Schreibweise übernehmen. Wie findet Ihr diese Schreibweise?

Die neue Funktionalität möchte ich nicht mehr missen. Zudem empfinde ich ein TDirectory.Exists() als angenehm lesbar und hinreichend selbstbeschreibend.

[Sir Rufo]

Viele von diesen Strukturen sind von .net inspiriert (was es ja nicht schlecht macht)

• TDirectory => Directory
• TFile => File
• TPath => Path

Wenn man sich die .net Struturen allerdings so anschaut, dann fragt man sich, wann das denn kommt, oder ob man das besser selber implementiert.

[alda]

Zitat:

Zitat von Sir Rufo (Beitrag 1311973)

Viele von diesen Strukturen sind von .net inspiriert (was es ja nicht schlecht macht)

• TDirectory => Directory
• TFile => File
• TPath => Path

Wenn man sich die .net Struturen allerdings so anschaut, dann fragt man sich, wann das denn kommt, oder ob man das besser selber implementiert.

Ich wollt schon sagen ... letztendlich endet es darin, dass man es selbst richtig macht - sitze ich zufälligerweise gerade auch dran :P die IOUtils wurden halt wieder von einem unterbezahlten Praktikanten programmiert :D

[bernau]

Zitat:

Zitat von alda (Beitrag 1311984)

Ich wollt schon sagen ... letztendlich endet es darin, dass man es selbst richtig macht - sitze ich zufälligerweise gerade auch dran :P die IOUtils wurden halt wieder von einem unterbezahlten Praktikanten programmiert :D

Begründung? Was ist schlecht oder funktioniert nicht?

[alda]

Zitat:

Zitat von bernau (Beitrag 1311986)

Zitat:

Zitat von alda (Beitrag 1311984)

Ich wollt schon sagen ... letztendlich endet es darin, dass man es selbst richtig macht - sitze ich zufälligerweise gerade auch dran :P die IOUtils wurden halt wieder von einem unterbezahlten Praktikanten programmiert :D

Begründung? Was ist schlecht oder funktioniert nicht?

Weil es nicht objektorientiert ist. Drei Records hingeklatscht und paar Klassenmethoden implementiert, fertig ist der Nudelsalat. Gerade beim Dateisystemzugriff wäre es schön wenn es "richtig" (Interfaced) gemacht worden wäre, sodass man das beim Testen wegmocken kann und nicht die komplette Unit überschreiben muss.

[bernau]

Zitat:

Zitat von alda (Beitrag 1311987)

Weil es nicht objektorientiert ist. Drei Records hingeklatscht und paar Klassenmethoden implementiert, fertig ist der Nudelsalat. Gerade beim Dateisystemzugriff wäre es schön wenn es "richtig" (Interfaced) gemacht worden wäre, sodass man das beim Testen wegmocken kann und nicht die komplette Unit überschreiben muss.

Muss es objektorientiert sein? Was ist an den Klassenmethoden falsch? Es macht genau das, was es soll. Ein paar Funktionen zusammenfassen, sodaß es "schön" aussieht.

Warum ist "Interfaced" = "richtig"? Warum sollte ich erst etwas instanzieren müssen, wenn es auch so geht.

Aber ich lerne gerne. Gib mal ein Beispiel, wie ein einfaches

Delphi-Quellcode:

TFile.exists(aFilePath)

bei dir aussieht.

[Sir Rufo]

Es geht hier nicht um das einfache

Delphi-Quellcode:

TFile.Exists

. Diese Methoden sind im Übrigen in .net analog umgesetzt (mit einer statischen Klasse).

Aber man hat dort eben nicht aufgehört und auch noch so nette Dinge wie DirectoryInfo, DriveInfo, FileInfo dort implementiert, die das Leben einfacher machen.

[alda]

Zitat:

Zitat von bernau (Beitrag 1311988)

Zitat:

Zitat von alda (Beitrag 1311987)

Weil es nicht objektorientiert ist. Drei Records hingeklatscht und paar Klassenmethoden implementiert, fertig ist der Nudelsalat. Gerade beim Dateisystemzugriff wäre es schön wenn es "richtig" (Interfaced) gemacht worden wäre, sodass man das beim Testen wegmocken kann und nicht die komplette Unit überschreiben muss.

Muss es objektorientiert sein? Was ist an den Klassenmethoden falsch? Es macht genau das, was es soll. Ein paar Funktionen zusammenfassen, sodaß es "schön" aussieht.

Warum ist "Interfaced" = "richtig"? Warum sollte ich erst etwas instanzieren müssen, wenn es auch so geht.

Aber ich lerne gerne. Gib mal ein Beispiel, wie ein einfaches

Delphi-Quellcode:

TFile.exists(aFilePath)

bei dir aussieht.

Dann haben wir wohl verschiedene Auffassungen von "schön" aussehen :-) In diesem Fall würde ich sagen: Ja das muss objektorientiert sein. Ich hab nichts gegen prozedurale Programmierung, die macht aber eben nur an wenigen Stellen Sinn.

Der Zugriff auf ein Dateisystem ist eigentlich dafür prädestiniert mit Abstraktionen/Schnittstellen zu arbeiten. So hat man dann nicht innerhalb seiner TFile.Exists(path) Methode seine 300 Zeilen Code (übertrieben) mit 40 IFDEFs (auch übetrieben :-)), sondern eine einheitliche, vollständige und korrekt benannte API für den Entwickler und dahinter die verschiedenen Implementierungen für OSX, Android, Windows, eben abhängig von der Plattform.

Außerdem hast Du mit so statischen vorgehensweisen wie "TFile.Do*(Pfad)" auch immer das Problem, dass Du durch dein Programm hinweg einen String mit Dir rumschleppst, den Du (wenn Du nicht gerade alleine arbeitest) zur Sicherheit vor jeder Verarbeitung überprüfst/auseinander nimmst -> ExtractFileExt, ExtractFilePath, ExtractFileName etc pp. Einfacher wäre auch hier eine IFile Schnittstelle die eine Datei repräsentiert und auf der ich ein IFile.Exists, IFile.FileExt, IFile.Location etc aufrufen kann - nie wieder unnötige String/Pfad Verarbeitungen.

Und wenn ich 1000-5000€ für die IDE/Sprache bezahle, dann erwarte ich auch dass ich für mein Geld was geboten bekomme - das ist zumindest meine Meinung ;-)

[bernau]

Zitat:

Zitat von Sir Rufo (Beitrag 1311989)

Es geht hier nicht um das einfache

Delphi-Quellcode:

TFile.Exists

. Diese Methoden sind im Übrigen in .net analog umgesetzt (mit einer statischen Klasse).

Aber man hat dort eben nicht aufgehört und auch noch so nette Dinge wie DirectoryInfo, DriveInfo, FileInfo dort implementiert, die das Leben einfacher machen.

Anscheinend hört Emba auch nicht auf zu entwickeln, bzw. sie fangen grade "wieder" an zu entwickeln. Sonst hätten sie z.B. TFile nicht gekapselt.

In den letzten 2-3 Jahren hat Delphi mehr zugelegt, als in den 10 Jahren davor (gefühlt). Daher bin ich sehr optimistisch, daß die Erweiterung der RTL hier nicht stehen bleibt und wir noch einiges erwarten können.

[bernau]

Zitat:

Zitat von alda (Beitrag 1311992)

Dann haben wir wohl verschiedene Auffassungen von "schön" aussehen :-)

TFile.exists sieht zumindest schöner aus als fileexists ;-)

Ich will nicht bestreiten, daß es noch besser geht. Aber dennoch kann ich den ersten Schritt positiv sehen und mich darüber freuen, daß die RTL erweitert wird und nicht nur ein paar Komponenten zugekauft werden, damit eine neue Delphi-Version erscheinen kann.

[alda]

Zitat:

Zitat von bernau (Beitrag 1311995)

Anscheinend hört Emba auch nicht auf zu entwickeln, bzw. sie fangen grade "wieder" an zu entwickeln. Sonst hätten sie z.B. TFile nicht gekapselt.

In den letzten 2-3 Jahren hat Delphi mehr zugelegt, als in den 10 Jahren davor (gefühlt). Daher bin ich sehr optimistisch, daß die Erweiterung der RTL hier nicht stehen bleibt und wir noch einiges erwarten können.

Dein zweiter Vorname scheint in der Tat Optimist zu sein :D Mit "Emba macht da inzwischen mehr" verbinde ich lediglich "mehr Bugs" und "keine Bugfixes" oder "Bugfixes in einer neueren Version, wie ich Sie gekauft habe" :-)

[Sir Rufo]

Zitat:

Zitat von bernau (Beitrag 1311995)

Anscheinend hört Emba auch nicht auf zu entwickeln, bzw. sie fangen grade "wieder" an zu entwickeln. Sonst hätten sie z.B. TFile nicht gekapselt.

Man kann darüber streiten, ob Abschreiben auch wirklich Entwickeln ist ... und wenn schon nur Abschreiben, dann doch bitte auch komplett.

Der Grund dafür sind allerdings die zusätzlichen Plattformen und das Bestreben Entwickler auch von anderen Sprachen zu bekommen. Und die sind meistens OOP gewohnt und keinen prozeduralen Stil.

Ja, ich liebe es auch, wenn ich etwas mit einem Directory veranstalten möchte, dass ich

Delphi-Quellcode:

TDirectory

eintippe und alle Möglichkeiten per Codevervollständigung aufgelistet werden. Denn genau das bringt Geschwindigkeit beim Programmieren.

Ich ärgere mich aber immer dann, wenn bei so einer Bibliothek auf der halben Strecke aufgehört wurde ... :roll:

Irgendwie beschleicht mich dann immer das Gefühl, die haben es zwar gesehen, aber sich dann gedacht "Ach, ist doch nur für Oma, das reicht jetzt so! Ich brauch das nicht!"

[Der schöne Günther]

Zitat:

Zitat von bernau (Beitrag 1311995)

In den letzten 2-3 Jahren hat Delphi mehr zugelegt, als in den 10 Jahren davor (gefühlt)

Ich bin eigentlich Optimist, aber dem würde ich widersprechen. Das "neue" TFile ist ab mindestens "2010" dabei, das sind sechs Jahre. Seitdem hat sich die Sprache auch kein bisschen mehr weiterentwickelt. Helfer für Klassen, in XE3. Aber sonst?

Über die RTL will ich nicht meckern. Ich ärgere mich da auch nicht so sehr wenn es nur "halbfertig" ist. Lieber halb als gar nicht. Bin wohl wirklich Optimist :-)

[alda]

Zitat:

Zitat von Sir Rufo (Beitrag 1312011)

Irgendwie beschleicht mich dann immer das Gefühl, die haben es zwar gesehen, aber sich dann gedacht "Ach, ist doch nur für Oma, das reicht jetzt so! Ich brauch das nicht!"

Genau so siehts aus, made my day :lol:

[rd3]

...

[Luckie]

Zitat:

Zitat von rd3 (Beitrag 1312053)

praktische with-Konstruktion

Du willst die Welt brennen sehen oder? :mrgreen: Nur mal so am Rande bemerkt, muss nicht weiter diskutiert werden. ;)

[Der schöne Günther]

Wir sollten uns echt langsam mal zusammentun und Quellcode sammeln

http://www.delphipraxis.net/182276-d...-projekte.html

Ich habe auch mittlerweile eine Menge an Klassen die bestimmt auch andere mal brauchen könnten. Wir sollten wirklich mal ein bisschen Gehirmsturm für eine halbwegs einheitliche Strukturierung und Philosophie (z.B. Teeren und Federn bei "with", ...) und eine gemeinsame Library aufbauen.

[bernau]

@rd3: Nenn mich altmodisch, aber bei einer Klassenfunktion, die sich FileInfo nennt, erwarte ich nicht die eigene Klasse instanziert zurück, sondern etwas was mir Informationen zu einer bestimmten Datei liefert.

Übrigens: with ist bäh ;-)

Bin echt überrascht, was Ihr so alles mit Dateifunktionen macht. In der Regel prüfe ich mit TFile.exists, ob eine Datei vorhanden ist. Meist wird dann eine andere Klasse (Z.b.TStringlist oder TMeinWuppdiObjekt )verwendet und dort gibt es die Funktion LoadFromFile. Muss also den Dateinamen sowiso übergeben. Mir fällt auf die schnelle nicht wirklich etwas ein, bei dem ich mehr als drei Funktionen von TFile hintereinander aufrufen würde.

Einzig die Implementation von TIniFile finde ich unglücklich, weil es als record deklariert ist. Eine Custom-Erweiterung mit eigenen Funktionen ist somit nicht wirklich praktikabel. Eine Klasse wäre da besser gewesen.

[Dejan Vu]

'with' ist nicht bä, sondern nur unpraktisch.

Nur um es noch einmal festzuhalten: TFile.Exists hat nichts, aber auch gar nichts mit OOP zu tun. TFile ist eine statische Klasse und das ist nichts anderes als eine Unit.

Der von alda skizzierte Ansatz wäre wirklich sehr angenehm, zumal ich dann auch auf der Ebene ordentliche (bzw. überhaupt) Unittests schreiben kann. Ansonsten ist das Mocken von 'TFile.Exists' auch nicht so einfach.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1312104)

'with' ist nicht bä, sondern nur unpraktisch.

Ist doch völlig wurscht, ob man jetzt "bä" oder "böse" oder "besser nicht verwenden" sagt. Fakt ist, daß die Verwendung von with gewisse Risiken birgt, die zu schwer auffindbaren Fehlern führen können und deshalb tunlichst vermieden werden sollte.

[bernau]

Zitat:

Zitat von Dejan Vu (Beitrag 1312104)

Nur um es noch einmal festzuhalten: TFile.Exists hat nichts, aber auch gar nichts mit OOP zu tun. TFile ist eine statische Klasse und das ist nichts anderes als eine Unit.

Ich habe nicht geschrieben, daß die jetzige Version OOP ist, sondern daß ich diese Schreibweise als sehr angenehm empfinde.

[alda]

Zitat:

Zitat von Dejan Vu (Beitrag 1312104)

Der von alda skizzierte Ansatz wäre wirklich sehr angenehm, zumal ich dann auch auf der Ebene ordentliche (bzw. überhaupt) Unittests schreiben kann. Ansonsten ist das Mocken von 'TFile.Exists' auch nicht so einfach.

Genau, und die einzige Möglichkeit die Du für solche "prozeduralen" Ansätze hast, ist die komplette Unit im Testprojekt zu überschreiben. Das geht dann aber halt auch nur ein einziges Mal innerhalb dieses Testprojektes :P

[Frickler]

Zitat:

Zitat von bernau (Beitrag 1312076)

Übrigens: with ist bäh ;-)

So, wie es Delphi aktuell macht, ja. Aber ein "with" wie in

Delphi-Quellcode:

with X = TMySpecialType.Create(12, 'hallo', Self) do
  ShowMessage(X.AsString);

fände ich persönlich ne Super-Idee.


(ist aus Modula-3)

[Stevie]

Zitat:

Zitat von Frickler (Beitrag 1314452)

Zitat:

Zitat von bernau (Beitrag 1312076)

Übrigens: with ist bäh ;-)

So, wie es Delphi aktuell macht, ja. Aber ein "with" wie in

Delphi-Quellcode:

with X = TMySpecialType.Create(12, 'hallo', Self) do
  ShowMessage(X.AsString);

fände ich persönlich ne Super-Idee.


(ist aus Modula-3)

Leider passt das nicht so ganz in Delphi wegen einigen Konzepten:

1. In Delphi müssen Variablen vordefiniert werden, es spart mir also nichtmal sonderlich viel Tiparbeit
2. In Delphi gibt es keinen kleineren Scope als eine Routine. Solch ein with sollte aber einen bilden, siehe using.

[mkinzler]

Dann müsste man halt mit compiler magic arbeiten.

Delphi-Quellcode:

with x = aClass.aSubClass.AnotherOne do
  x.Attribut := <IrgendWas>;

->

Delphi-Quellcode:

 aClass.aSubClass.AnotherOne.Attribut := <IrgendWas>;

Oder noch besser den Scope verfeinern.

[himitsu]

Zitat:

1. In Delphi müssen Variablen vordefiniert werden, es spart mir also nichtmal sonderlich viel Tiparbeit

Jain, denn wenn man es so sieht, dann kann Delphi sowas schon sehr lange, aber leider nicht in einem with.

siehe

Delphi-Quellcode:

try

except
  on E: Exception do
    ShowMessage(E.Message);
end;

entspricht in etwa

Delphi-Quellcode:

var
  E: Exception;

try

except
  if ExceptObject is Exception then begin
    E := Exception(ExceptObject);
    ShowMessage(E.Message);
  end;
end;

und Self ist auch sowas.


PS:

Delphi-Quellcode:

with X = TMySpecialType.Create(12, 'hallo', Self) do

ginge doch?
oder meint ihr

Delphi-Quellcode:

with X := TMySpecialType.Create(12, 'hallo', Self) do

:zwinker:

Und sowas wie "Self" für die temporäre "Variable" des WITH wäre auch schön, wenn man schon das X:= nicht selber angeben darf.

Delphi-Quellcode:

with Memo1, Memo1.Lines, Memo1.irgendwasanderes do
  Text := Value[1] + sonstwas;

:roll::roll::roll:

[uligerhardt]

Zitat:

Zitat von Perlsau (Beitrag 1312107)

Fakt ist, daß die Verwendung von with gewisse Risiken birgt, die zu schwer auffindbaren Fehlern führen können und deshalb tunlichst vermieden werden sollte.

Fakt ist, daß Programmieren gewisse Risiken birgt, die zu schwer auffindbaren Fehlern führen können und deshalb tunlichst vermieden werden sollte. :mrgreen: