UnitOptimizer

[DieDolly]

Mal als Neuling-line eine Frage.
Was macht die Unit? Ich werde aus dem Video und der Einleitung nicht schlau.

[stahli]

Meinst Du, was der Optimizer macht?

Schaust Du mal bitte unter Beitrag #3? Da hatte ich das nochmal zusammengefasst.
Ansonsten gehe ich gern nochmal darauf ein, aber vielleicht klären sich die Fragen ja schon damit.

[stahli]

Ich habe eine Lösung für weiche Umbrüche gefunden. :-)

#0 ist für den Editor ein EOF - ist also untauglich.
Mit #27 funktioniert es aber erst mal gut.
Im Editor wird ein kleines Kästchen dargestellt, das aber (soweit ich testen konnte) nirgends stört.

Sofern sich doch mal noch Probleme ergeben, könnte ich das ESCAPE auch durch "//" ersetzen, das dann am Ende einer Zeile als weiches LineBreak interpretiert werden kann.
Fall jemand zufällig weiß, dass das ESCAPE unter bestimmten Umständen kritisch sein kann, dann gebt bitte mal Bescheid.

Bei neuen Formatierungen werden diese Umbrüche gegebenenfalls durch neue ersetzt.

Im Bild habe ich mal einige aufeinanderfolgende Optimierungen und Änderungen dargestellt.
Am Kästchen ist zu sehen, dass hier ein weicher Umbruch ist, der bei der nächsten Optimierung ggf. korrigiert wird. :-)

[p80286]

Irritierender Weise erfährt man in der Delphi-Hilfe nicht was die aktuellen Whitespaces sind.
Ich meine mich zu erinnern, das x1B(#27) ein Whitespace ist, aber das bezieht sich wohl auf (Turbo)Pascal.
Vielleicht kommst du an die aktuelle Backus-Naur-Form, da sollte alles drin stehen.

Gruß
K-H

[stahli]

@p80286

Ich wusste nicht mal, dass eine derartige standardisierte Dokumentation gibt.
Gefunden habe ich nichts passendes. Man kann sich ja auch nicht darauf verlassen, dass es bei einer aktuellen Regelung dauerhaft bleibt.
Ich werde das erst mal bei #27 belassen und einen Plan B in der Hinterhand behalten. Es kann ja auch mal sein, dass andere Tools nicht mit dem #27 klar kommen oder das selbst anders interpretieren.


@all

Ich könnte mir auch gut Einrückungen von SQL-Statements vorstellen.
Hätte da jemand Interesse?
Ich selbst brauche das nicht, aber ich könnte das mit einplanen.

Das könnte dann so aussehen:

Code:

  SQL1.Text := 'select * from Table.db '
             + 'where X=1 '
             + 'order by Y';

oder so:

Code:

  SQL1.Text := 'select * from Table.db' + #13#10
             + 'where X=1' + #13#10
             + 'order by Y';

Der Code würde dann harte (unveränderliche) Linebreaks enthalten, aber das "+" als erstes Zeichen in der nächsten Zeile und das fehlende Semikolon in der vorherigen würde zum Einrücken des Textes führen.

[p80286]

Ich hab da was in der D7 Hilfe gefunden:

Zitat:

Syntaktische Elemente

Delphi verwendet den ASCII-Zeichensatz mit den Buchstaben A bis Z und a bis z, den Ziffern 0 bis 9 und weiteren Standardzeichen. Die Sprache unterscheidet nicht zwischen Groß- und Kleinschreibung. Das Leerzeichen (ASCII 32) und die Steuerzeichen (ASCII 0 bis 31 einschließlich ASCII 13 für Zeilenvorschub) werden als Blanks bezeichnet.

Zugegeben nicht mehr ganz aktuell aber vielleicht ein Einstieg.
Angeblich soll die BNF sich auch in der Hilfe befinden, aber bisher hab ich sie noch nicht gefunden.

Gruß
K-H

[stahli]

Ich habe jetzt eine kleine Demoexe mit der man Vorschauen von optimierten Units anzeigen kann.
Optional gibt es vorerst die Möglichkeit, in Uses-Klauseln Units untereinander anordnen zu lassen.

Ist noch sehr provisorisch. Später werde ich die hier auch mal zum Testen hochladen.
Die Optionen sollen natürlich noch ausgebaut werden.

Anbei mal ein Screenshot von zwei Formatierungen der Uses-Klausel und hier ein kurzes Video: https://youtu.be/KHxoeZCwk7I (3min).

[stahli]

Eine Frage:

Macht es Sinn, Getter und Setter in Interfacedeklarationen in Regions zu verpacken?

Delphi-Quellcode:

  IWord = interface( IResultText )
    [sid_Word]
    {$REGION 'Getter+Setter'}
    function  _get_Text: string;
    procedure _set_Text( const Value: string );
    function  _get_PosMarkerList: TList<IPosMarker>;
    procedure _set_PosMarkerList( const Value: TList<IPosMarker>);
    function  IsSpace: Boolean;
    {$ENDREGION}
    function  IsFilled: Boolean;
    property  Text: string read _get_Text write _set_Text;
    function  AsText: string;
    property  PosMarkerList: TList<IPosMarker> read _get_PosMarkerList write _set_PosMarkerList;
  end;

Getter und Setter sind ja quasi nur Hilfskonstrukte und für die Nutzung und Verständnis des Interfaces nicht wirklich relevant.
Zugeklappt sieht das gut aus. Aber der Optimizer kann sicher nicht gezielt DIESE Regionen zuklappen.

Ich könnte auch eine Leerzeile zwischen Gettern+Settern und dem Rest einfügen.

Ok, dann ist die Region auch nicht wirklich störend.
Oder gibt es neben den optischen Bewertungen noch Gründe gegen Regionen (Probleme beim Debugging oder anspringen von Codezeilen o.ä.)?

Was meint Ihr zur Separierung von Gettern+Settern vom Rest eines Interfaces?

- Region
- Leerzeile
- Leerzeile mit //
- gar keine Trennung

[TiGü]

Zitat:

Was meint Ihr zur Separierung von Gettern+Settern vom Rest eines Interfaces?

- Region
- Leerzeile
- Leerzeile mit //
- gar keine Trennung

Ja, alles. Einstellbar machen.

[stahli]

Ich habe jetzt erst mal die Regionen fix drin.

Natürlich kann ich da je nach Bedarf mal noch verschiedene Optionen anbieten, aber ich werde jetzt vorrangig erst mal ein Standardverhalten umsetzen und die Logik möglichst übersichtlich halten (ist wirklich schon komplex genug).

Anbei mal ein paar aktuelle Screenshots.

In der DP lässt sich der formatierte Code nicht gut darstellen aber Ihr könnt Euch mal aus dem Anhang eine Beispielunit mit Eurem Delphi öffnen.
Die Regionen sind bei mir dann direkt zugeklappt. Ansonsten müsstet Ihr diese mal noch selber zusammenklappen um einen wirklichen Eindruck zu bekommen, wie sich das so anfühlt.

Mir gefällt das so schon sehr gut.

Ich suche jetzt noch eine Funktion in den OTA, mit der der Optimizer alle Regionen nach der Arbeit selbständig zusammenklappen kann.
Grundsätzlich komme ich jetzt ganz gut voran... :-)