![]() |
AW: Interface-Unterstützung
Ich abonnier deinen Kanaaal!!!
EDIT: Huch, ich hatte das alles groß geschrieben aber die DP hat das offenbar zensiert... |
AW: Interface-Unterstützung
Siehe Marcos Kommentare.
![]() ![]() |
AW: Interface-Unterstützung
Zitat:
Aber schöner ist natürlich Code Explorer zu benutzen. Zitat:
|
AW: Interface-Unterstützung
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
"Name", Tab, "Typname", Enter fertig |
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:
steht.
property X: Interger read write;
Entweder konnten
Delphi-Quellcode:
und
function _get_X: Integer;
Delphi-Quellcode:
physisch im Code eingebaut werden oder der Compiler tut einfach so, als würden die dort stehen...
procedure _set_X(const aValue: Integer);
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... |
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. |
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:
das hier
type
TMyClass = class published property Name: string read FName write SetName; end;
Delphi-Quellcode:
oder
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;
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; |
AW: Interface-Unterstützung
Zitat:
|
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... |
AW: Interface-Unterstützung
Zitat:
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:
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 06:04 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz