Interface-Unterstützung

[stahli]

Ich abonnier deinen Kanaaal!!!


EDIT: Huch, ich hatte das alles groß geschrieben aber die DP hat das offenbar zensiert...

[Stevie]

Siehe Marcos Kommentare.

https://quality.embarcadero.com/browse/RSP-13306
https://quality.embarcadero.com/browse/RSP-16316

[jaenicke]

Zitat von stahli:

Ein automatisches Feld sollte die Codevervollständigung m.E. anlegen und im Getter/Setter verwenden, wenn Getter und Setter erzeugt werden.

Ohne Code Explorer habe ich das immer so gemacht:

• Ich schreibe property BlaBlub: Integer;
• Ich drücke Strg + Shift + C
• Nun habe ich: property BlaBlub: Integer read FBlaBlub write SetBlaBlub;
• Nun ersetze ich F durch Get und Set durch F und drücke wieder Strg + Shift + C
• Nun habe ich privates Feld, Getter und Setter
• Nun muss ich nur noch das F nach write wieder in Set ändern

Am meisten lohnt sich das natürlich, wenn man mehrere Properties gleichzeitig anlegt und gleich mehrfach "read F" durch "read Get" ersetzen kann usw.

Aber schöner ist natürlich Code Explorer zu benutzen.

Zitat von Stevie:

Siehe Marcos Kommentare.

https://quality.embarcadero.com/browse/RSP-13306
https://quality.embarcadero.com/browse/RSP-16316

Die Idee gefällt mir zwar überhaupt nicht, aber mal schauen was daraus wird...

[himitsu]

Zitat von jaenicke:

Ohne Code Explorer habe ich das immer so gemacht:

• Ich schreibe property BlaBlub: Integer;
• Ich drücke Strg + Shift + C
• Nun habe ich: property BlaBlub: Integer read FBlaBlub write SetBlaBlub;
• Nun ersetze ich F durch Get und Set durch F und drücke wieder Strg + Shift + C
• Nun habe ich privates Feld, Getter und Setter
• Nun muss ich nur noch das F nach write wieder in Set ändern

Strg+Leertaste, "prop", Typ auswählen, Enter
"Name", Tab, "Typname", Enter
fertig

[stahli]

@himitsu

Da hast Du aber kein privates Feld erzeugt.
Getter und Setter liegen irgendwo in der Unit.
Du musst also das private Feld definieren, die Methoden suchen und dort immer den selben Quatsch reinschreiben.
Das halte ich für völlig unnötig und hier sollte die IDE einem einfach etwas Arbeit abnehmen.


@jaenicke

Was gefällt Dir an der Idee aus Stevies Link nicht? Es würde doch einfach mehr Freiheiten ermöglichen.
Ich fände das schon gut.
So weit wollte ich mit meiner Idee aber eigentlich gar nicht gehen, bzw. hatte ich ein anderes Ziel.
Ich will einfach weniger schreiben müssen und weniger Redundanzen haben.
So könnte der Compiler einfach normale Getter und Setter erzeugen bzw. voraussetzen, wenn im Interface
property X: Interger read write; steht.
Entweder konnten function _get_X: Integer; und procedure _set_X(const aValue: Integer); physisch im Code eingebaut werden oder der Compiler tut einfach so, als würden die dort stehen...
Der Programmierer könnte auch unverändert Getter und Setter vollständig selbst deklarieren, so dass dann alles beim alten bliebe.
Da müsste also an den Interfaces selbst (im Hintergrund) gar nichts geändert werden.
Standards müsste man halt nicht ständig wiederholt komplett ausschreiben.
Gleiches dann in den Klassen und das Programmiererleben wäre sehr viel einfacher...

[stahli]

@MMX-Cracks

MMX bietet aber nicht die Möglichkeit, die Klasse durch fehlende Interface-Members zu ergänzen - oder?
Ein Property oder Methode zu erzeugen ist schon ok, aber noch nicht ganz mein gewünschtes Feature.

[himitsu]

Die vordeffinierten Templates sind nicht immer das Beste, aber man kann damit sehr viel mehr machen, auch inkl. dem Anlegen von Feldern und der Zuweisung im Setter, samt Prüfung auf Änderung uvm.

PS: Strg+Shift+C macht aus dem

Delphi-Quellcode:

type
  TMyClass = class
  published
    property Name: string read FName write SetName;
  end;

das hier

Delphi-Quellcode:

type
  TMyClass = class
  private
    FName: string;
    procedure SetName(const Value: string);
  published
    property Name: string read FName write SetName;
  end;

{ TMyClass }

procedure TMyClass.SetName(const Value: string);
begin
  FName := Value;
end;

oder

Delphi-Quellcode:

// property Name: string read GetName write FName;

type
  TMyClass = class
  private
    FName: string;
    function GetName: string;
  published
    property Name: string read GetName write FName;
  end;

{ TMyClass }

function TMyClass.GetName: string;
begin
  Result := FName;
end;

Delphi-Quellcode:

// property Name: string read GetName write SetName;

type
  TMyClass = class
  private
    function GetName: string;
    procedure SetName(const Value: string);
  published
    property Name: string read GetName write SetName;
  end;

{ TMyClass }

function TMyClass.GetName: string;
begin

end;

procedure TMyClass.SetName(const Value: string);
begin

end;

[Uwe Raabe]

Zitat von stahli:

MMX bietet aber nicht die Möglichkeit, die Klasse durch fehlende Interface-Members zu ergänzen - oder?

Das Interface per Drag-Drop oder Copy-Paste auf die implementierende Klasse ziehen.

[stahli]

Ah, ok, danke!

Das Erzeugen von Propertys im Interface und Übernahme in der Klasse gefällt mir aber auch noch nicht richtig.

Ich versuche mal mein Tool weiter. Mal sehen, wie es wird...

[jaenicke]

Zitat von stahli:

So könnte der Compiler einfach normale Getter und Setter erzeugen bzw. voraussetzen, wenn im Interface
property X: Interger read write; steht.
Entweder konnten function _get_X: Integer; und procedure _set_X(const aValue: Integer); physisch im Code eingebaut werden oder der Compiler tut einfach so, als würden die dort stehen...

Die Logik, dass der Setter SetXyz und der Getter GetXyz heißt, gibt es in Delphi ja schon. Da braucht man nicht mit den unsäglichen Unterstrichen anfangen. In anderen Sprachen sind die üblich, in Delphi entsprechend des Styleguides kein guter Programmierstil. Und das finde ich auch gut so.

Ich finde was die Idee angeht einfach, dass man schon explizit schreiben müssen sollte was man meint. Solch eine Automatik führt nur zu Missverständnissen und Bugs.
Ich merke immer wieder mal, dass ich in anderen Sprachen mehrfach hinschauen muss was genau eigentlich gemeint ist, während es in Delphi einfach so klar ist. Ich finde, dass man diese Einfachheit durchaus beibehalten sollte.

Zitat von stahli:

Ich will einfach weniger schreiben müssen und weniger Redundanzen haben.

Redundanz, klar, das ist ein Argument, aber das mit dem weniger schreiben wollen finde ich als Entwickler unangebracht. Denn gute Bezeichner usw. sollten ohnehin nicht ganz kurz sein usw., so dass man ohnehin nicht schreibfaul sein sollte, wenn man guten Code schreiben möchte.

Und insbesondere bei Interfaces und Klassen gibt es ja nicht mehr zu schreiben, sondern das wäre im Gegenteil mit der angedachten neuen Lösung der Fall. Aktuell schreibe ich die Deklaration einmal und kopiere diese dann herüber in Interface oder Klasse, je nachdem. Der Schreibaufwand wäre also höher, wenn man in Klasse und Interface unterschiedlich aussehende Deklarationen benutzen würde. Denn die müsste man dann ja wirklich manuell doppelt schreiben...