Delphi-PRAXiS
Seite 2 von 7     12 34     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Die Delphi-IDE (https://www.delphipraxis.net/62-die-delphi-ide/)
-   -   Interface-Unterstützung (https://www.delphipraxis.net/193733-interface-unterstuetzung.html)

stahli 2. Sep 2017 17:35

AW: Interface-Unterstützung
 
Ich abonnier deinen Kanaaal!!!


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

Stevie 2. Sep 2017 19:15

AW: Interface-Unterstützung
 
Siehe Marcos Kommentare.

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

jaenicke 2. Sep 2017 21:58

AW: Interface-Unterstützung
 
Zitat:

Zitat von stahli (Beitrag 1380187)
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
    Delphi-Quellcode:
    property BlaBlub: Integer;
  • Ich drücke Strg + Shift + C
  • Nun habe ich:
    Delphi-Quellcode:
    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:

Zitat von Stevie (Beitrag 1380194)

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

himitsu 2. Sep 2017 22:24

AW: Interface-Unterstützung
 
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:

Zitat von jaenicke (Beitrag 1380202)
Ohne Code Explorer habe ich das immer so gemacht:
  • Ich schreibe
    Delphi-Quellcode:
    property BlaBlub: Integer;
  • Ich drücke Strg + Shift + C
  • Nun habe ich:
    Delphi-Quellcode:
    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 2. Sep 2017 22:54

AW: Interface-Unterstützung
 
@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
Delphi-Quellcode:
property X: Interger read write;
steht.
Entweder konnten
Delphi-Quellcode:
function _get_X: Integer;
und
Delphi-Quellcode:
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 2. Sep 2017 23:42

AW: Interface-Unterstützung
 
@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 3. Sep 2017 00:18

AW: Interface-Unterstützung
 
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 3. Sep 2017 08:08

AW: Interface-Unterstützung
 
Zitat:

Zitat von stahli (Beitrag 1380206)
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 3. Sep 2017 08:22

AW: Interface-Unterstützung
 
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 3. Sep 2017 11:53

AW: Interface-Unterstützung
 
Zitat:

Zitat von stahli (Beitrag 1380205)
So könnte der Compiler einfach normale Getter und Setter erzeugen bzw. voraussetzen, wenn im Interface
Delphi-Quellcode:
property X: Interger read write;
steht.
Entweder konnten
Delphi-Quellcode:
function _get_X: Integer;
und
Delphi-Quellcode:
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:

Zitat von stahli (Beitrag 1380205)
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...


Alle Zeitangaben in WEZ +1. Es ist jetzt 13:07 Uhr.
Seite 2 von 7     12 34     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz