"forward" property Felder/getter/setter?

Forum für alles rund um die MSEide und MSEgui
pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: "forward" property Felder/getter/setter?

Beitrag von pluto »

Ich sehe einfach kein Vorteil dadrin. Klassen als forward zu erstellen hat natürlich vorteile, aber property's?
Kannst du ein paar Beispiele bringen, wozu das dienen soll?

Weil, ich leite ja von einer "Grundklasse" ab wo es diese Eigenschaften gibt.
Es sei denn, man könnte den Datentyp weg lassen. Dann hätte es einen gewissen Vorteile.

Ich würde lieber Eigenschaften überschreiben können:
In der Basis Klasse wurde eine Eigenschaft erstellt mit einem Datentyp, diesen würde ich in einer weiteren klasse gerne anpassen können.
MFG
Michael Springwald

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: "forward" property Felder/getter/setter?

Beitrag von mse »

Ich bin nicht sicher, ob du richtig verstanden hast.
In Free Pascal ist es so, dass Felder und getter() oder setter() Prozeduren definiert werden müssen, bevor sie in properties verwendet werden können. Das führt dazu, dass "public" properties nach ihren "private" oder "protected" Felder/getter()/setter() definiert werden müssen.

Code: Alles auswählen

 
 TTest = class(TBase)
  private
   fprop1: int32;
   function getprop2(): flo64;
   procedure setprop2(const avalue: flo64);
  public
   constructor create(const initvalue: flo64);
   property prop1: int32 read fprop1 write fprop1;
   property prop2: flo64 read getprop2 write setprop2;
 end;
 

Ich finde für Benutzer der Klasse wäre es praktischer, wenn die "public" Elemente direkt zu Beginn der Klassendefinition angeordnet wären wo auch die Code-Navigation der IDE hinspringt. Darum verzichtet MSElang auf die Forderung Felder, getter() und setter() vor den properties zu definieren. Die Klasse kann also auch so definiert werden:

Code: Alles auswählen

 
 TTest = class(TBase)
  constructor create(const initvalue: flo64);
  property prop1: int32 read fprop1 write fprop1;
  property prop2: flo64 read getprop2 write setprop2;
 
  private
   fprop1: int32;
   function getprop2(): flo64;
   procedure setprop2(const avalue: flo64);
 end;
 

Die für die Klassenutzer wichtigen "public"-Elemente sind nun alle zu Beginn der Klasse aufgeführt und von den Interna klar getrennt. Die Standardsichtbarkeit in MSElang ist "public". "published" gibt es nicht, da RTTI und Sichtbarkeit voneinander unabhängig sind.
Die Frage war, was dagegen spricht, dies zuzulassen. Die geäusserten Bedenken waren etwas überspitzt formuliert:
- Nicht im Sinne von Niklaus Wirth.
- Verwirrend da ungewohnt.
- Es sollen keine Verbesserungen zur Lesbarkeit in die Sprachstruktur eingebaut werden, welche auch durch IDE-Funktionen simuliert werden könnten.

Die ersten beiden Punkte fallen meines Erachtens für eine neue Programmiersprache nicht in Betracht.
Der dritte leuchtet mir nicht ein. Warum muss eine Programmiersprache so konzipiert sein, dass sie nur mit einer IDE lesbar ist?

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: "forward" property Felder/getter/setter?

Beitrag von pluto »

In Free Pascal ist es so, dass Felder und getter() oder setter() Prozeduren definiert werden müssen, bevor sie in properties verwendet werden können.

Ja.

Die Klasse kann also auch so definiert werden:

Das würde aber dann nicht mehr "Aufgeräumter" Code sein. Bei Pascal finde ich es gerade schön, dass alles "aufgeräumt" ist.

Der dritte leuchtet mir nicht ein. Warum muss eine Programmiersprache so konzipiert sein, dass sie nur mit einer IDE lesbar ist?

Da gebe ich dir durchaus recht.
Aber wie gesagt: In Pascal hat alles seinen Platz. Nachher möchtest du noch, dass Variablen überall im Code definiert werden können, praktisch wie in C oder du frühst den ? Operator ein.

Sollte die Grundstruktur von Pascal so Radikal geändert werden?

Mein Vorschlag ist es: Probiere es aus, ob es angenommen wird. Vielleicht fällt ja bei der Nutzung doch noch Vorteile oder Nachteile auf, die jetzt noch nicht bekannt sind.
MFG
Michael Springwald

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: "forward" property Felder/getter/setter?

Beitrag von mse »

Bitte erkläre was hier

Code: Alles auswählen

 
TTest = class(TBase)
  private
   fprop1: int32;
   function getprop2(): flo64;
   procedure setprop2(const avalue: flo64);
  public
   constructor create(const initvalue: flo64);
   property prop1: int32 read fprop1 write fprop1;
   property prop2: flo64 read getprop2 write setprop2;
 end;
 

aufgeräumter ist als hier

Code: Alles auswählen

 
 TTest = class(TBase)
  constructor create(const initvalue: flo64);
  property prop1: int32 read fprop1 write fprop1;
  property prop2: flo64 read getprop2 write setprop2;
 
  private
   fprop1: int32;
   function getprop2(): flo64;
   procedure setprop2(const avalue: flo64);
 end;
 

Nachher möchtest du noch, dass Variablen überall im Code definiert werden können, praktisch wie in C oder du frühst den ? Operator ein.

Wie kommst du darauf?

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: "forward" property Felder/getter/setter?

Beitrag von pluto »

Bitte erkläre was hier

Ganz einfach, dass erste ist "Logisch". Du musst erst die Sachen "Bauen", bevor du sie verwenden kannst.

Du kannst ja auch schlecht ein Dach auf ein Haus setzten, welches noch nicht da ist oder?
Du kannst zwar alles vorbereiten, aber was soll das Dach halten?

Der Pascal Entwickler erwartet einfach, dass es so ist, wie im ersten Beispiel. Wenn du es jetzt änderst, muss er sich daran gewöhnen.
Das ist die Unordnung, von der ich gesprochen habe.
Alles ist in Pascal klar Strukturiert. Auch was property's und die Getter und Setter Methoden angeht.
Es bringt einfach die Klare Line von Pascal durcheinander.

Warum nutzen wir Pascal/Object Pascal? Wegen den Klaren und Eindeutigen Strukturen.

Bei Klassen kann ich es verstehen: Stell dir eine Klasse vor, die eine andere Klasse braucht, aber diese Klasse gibt es einfach noch nicht.

Wie kommst du darauf?

Wenn man erst mal Grundlegende Sachen anfängt zu ändern, kommt Irgendwann so ein Gedanke.
und mal ehrlich: Den ?(Ternary Operator) Operator finde ich schon irgendwie Praktisch.
MFG
Michael Springwald

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: "forward" property Felder/getter/setter?

Beitrag von mse »

Es geht darum, mit den Erfahrungen von 40 Jahren Programmierung eine produktive Universal-Programmiersprache zu entwickeln. Die Ziele sind hier definiert:
https://gitlab.com/mseide-msegui/mselang/wikis/home
Pascal Programmierer sind schon ein seltsames Völkchen. ;-)

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: "forward" property Felder/getter/setter?

Beitrag von pluto »

Es geht darum, mit den Erfahrungen von 40 Jahren Programmierung eine produktive Universal-Programmiersprache zu entwickeln. Die Ziele sind hier definiert:

Die Idee ist auch nicht schlecht.
Vielleicht kannst du ja noch property's als forward definieren.
Das hätte einige Vorteile.
Stellt dir eine Klasse vor, die nur ein Propert value hat ohne Datentyp.
Erst in der nächsten Klasse wird diese "hinzugefügt".

Pascal Programmierer sind schon ein seltsames Völkchen.

Das unterscheidet uns von anderen Programmieren.
Überlegt mal, was für ein Unsinn in C hinzugefügt wurde, nur weil es machbar ist/war.
Aber genau damit gibt es immer wieder Probleme.
MFG
Michael Springwald

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: "forward" property Felder/getter/setter?

Beitrag von mse »

pluto hat geschrieben:
Vielleicht kannst du ja noch property's als forward definieren.
Das hätte einige Vorteile.
Stellt dir eine Klasse vor, die nur ein Propert value hat ohne Datentyp.
Erst in der nächsten Klasse wird diese "hinzugefügt".

Kannst du ein konkretes Beispiel machen?

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: "forward" property Felder/getter/setter?

Beitrag von mse »

pluto hat geschrieben:
Bitte erkläre was hier

Ganz einfach, dass erste ist "Logisch". Du musst erst die Sachen "Bauen", bevor du sie verwenden kannst.

Der Datentyp ist in der Property immerhin schon definiert. Das ist ja bereits sehr ordentlich und aufgeräumt. Was fehlt ist die Implementierung und die kommt in Pascal ja immer nach der Definition. So gesehen ist

Code: Alles auswählen

 
TTest = class(TBase)
  private
   fprop1: int32;
   function getprop2(): flo64;
   procedure setprop2(const avalue: flo64);
  public
   constructor create(const initvalue: flo64);
   property prop1: int32 read fprop1 write fprop1;
   property prop2: flo64 read getprop2 write setprop2;
 end;
 

nicht Pascal-like, da die Implementierung *vor* der Definition geschrieben wird. Es ist ja auch gar kein Pascal sondern Delphi...

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: "forward" property Felder/getter/setter?

Beitrag von pluto »

Kannst du ein konkretes Beispiel machen?

Klar. Stell dir vor, du möchtest ein CSS Parser schreiben.
Dieser soll die Daten in eine Dynamische Struktur einlesen.
Die CSS Felder haben aber unterschiedliche Datentypen.
Einige sind speichern Farb Werte also TColor, andere einfache Strings oder intergers.

Nun wäre es Praktisch wenn man eine Klasse wie folgt schreiben könnte:
Ich füge in diesen Beispiel ein Property hinzu. Dieses Property nenne ich mal Value. Es hat kein Getter oder Setter und KEIN Datentyp.
(Praktischerweise sollte man noch ein Property Name hinzufügen).
Nun leite ich von dieser Klasse eine weitere ab: TCSSColor z.b.
In dieser füge ich dem Property ein Datentyp hinzu und die jeweiligen Getter und Setter Methoden / oder Felder.
Das wäre in diesen Fall extrem Praktisch.
Weil so könnte ich eine Variable von Typ der Grundklasse erstellen, und alle hätten eine Eigenschaft Value.

In meinen CSS Parser Klassen, muss ich Value immer als String speichern. Damit es einheitlich wird und ich nicht immer Casten muss.

Ich kenne natürlich auch ein Trick, wie ich dem recht nah komme(Ich komme gerade auf das Schlüsselwort nicht).

Aber kannst du mir folgen?

Das ist ja bereits sehr ordentlich und aufgeräumt. Was fehlt ist die Implementierung und die kommt in Pascal ja immer nach der Definition. So gesehen ist

Was mich einfach an deinem Vorschlag stört ist, dass es bei dir genau andersherum wäre:
Du Definierst erst die Eigenschaft und dann die Getter und Setter Methoden. Wo ist da der Vorteil, deiner Meinung nach?
MFG
Michael Springwald

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: "forward" property Felder/getter/setter?

Beitrag von mse »

pluto hat geschrieben:
Kannst du ein konkretes Beispiel machen?

Klar. Stell dir vor, du möchtest ein CSS Parser schreiben.
[...]

Bitte mache ein Beispiel mit code.
Das ist ja bereits sehr ordentlich und aufgeräumt. Was fehlt ist die Implementierung und die kommt in Pascal ja immer nach der Definition. So gesehen ist

Was mich einfach an deinem Vorschlag stört ist, dass es bei dir genau andersherum wäre:
Du Definierst erst die Eigenschaft und dann die Getter und Setter Methoden.

Die Property ist die Typendefinition, getter() und setter() die Implementierung und die sollte deiner Aussage nach ja nach der Definition kommen. Du siehst, so eindeutig ist die Sache nicht. ;-)
Wo ist da der Vorteil, deiner Meinung nach?

Ich wiederhole:
Ich finde für Benutzer der Klasse wäre es praktischer, wenn die "public" Elemente direkt zu Beginn der Klassendefinition angeordnet wären wo auch die Code-Navigation der IDE hinspringt. Darum verzichtet MSElang auf die Forderung Felder, getter() und setter() vor den properties zu definieren. Die Klasse kann also auch so definiert werden:

Code: Alles auswählen

 
 
 TTest = class(TBase)
  constructor create(const initvalue: flo64);
  property prop1: int32 read fprop1 write fprop1;
  property prop2: flo64 read getprop2 write setprop2;
 
  private
   fprop1: int32;
   function getprop2(): flo64;
   procedure setprop2(const avalue: flo64);
 end;
 


Die für die Klassenutzer wichtigen "public"-Elemente sind nun alle zu Beginn der Klasse aufgeführt und von den Interna klar getrennt. Die Standardsichtbarkeit in MSElang ist "public". "published" gibt es nicht, da RTTI und Sichtbarkeit voneinander unabhängig sind.

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: "forward" property Felder/getter/setter?

Beitrag von pluto »

Bitte mache ein Beispiel mit code.

Bitte:

Code: Alles auswählen

 
  TPLBaseCss = class
   ....
   property value;
 
   TPLBaseCSS_Color = classc(TPLBaseCSS)
     ....
     property Value:TColor read GetValue write SetValue;
 

So einfach stelle ich es mir vor.

Die Property ist die Typendefinition, getter() und setter() die Implementierung und die sollte deiner Aussage nach ja nach der Definition kommen. Du siehst, so eindeutig ist die Sache nicht.

Gut. Da gebe ich dir recht. Die Reihenfolge ist nicht so wie sie sein sollte.
In diesen Fall müsste man den Code von Hinten nach Vorne lesen(jedenfalls den Klassen Header).

Ich wiederhole:

Das sehe ich nicht als Vorteil an.
Weil zum Beispiel kein Sichtbarkeitsfeld angeben wird constructor. Nun könnte man annehmen das ist Standard bei Object Pascal.
Es sieht einfach nicht richtig aus. Auch wenn es Logisch(nun weiß ich es) eher hinkommt(Weil wir den Code von Vorne nach Hinten lesen).


Die für die Klassenutzer wichtigen "public"-Elemente sind nun alle zu Beginn der Klasse aufgeführt und von den Interna klar getrennt.

Das ist ja jetzt auch schon gegeben, wenn die Methoden in "private" definiert werden. Wo ist das Problem?
MFG
Michael Springwald

mse
Beiträge: 2013
Registriert: Do 16. Okt 2008, 10:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
CPU-Target: x86,x64,ARM

Re: "forward" property Felder/getter/setter?

Beitrag von mse »

pluto hat geschrieben:
Bitte mache ein Beispiel mit code.

Bitte:

Code: Alles auswählen

 
  TPLBaseCss = class
   ....
   property value;
 
   TPLBaseCSS_Color = classc(TPLBaseCSS)
     ....
     property Value:TColor read GetValue write SetValue;
 

So einfach stelle ich es mir vor.

Bitte zeige auch noch die Verwendung der Klassen. Ich sehe nicht, was du erreichen willst.
Ich wiederhole:

Das sehe ich nicht als Vorteil an.
Weil zum Beispiel kein Sichtbarkeitsfeld angeben wird constructor.

Man kann "public" auch explizit angeben wenn man will:

Code: Alles auswählen

 
 TTest = class(TBase)
  public
   constructor create(const initvalue: flo64);
   property prop1: int32 read fprop1 write fprop1;
   property prop2: flo64 read getprop2 write setprop2;
 
  private
   fprop1: int32;
   function getprop2(): flo64;
   procedure setprop2(const avalue: flo64);
 end;
 

Schreibst du in einer Form auch "published" zu Beginn?

Code: Alles auswählen

 
type
 TForm1 = class(TForm)
  published
   TEdit1: TEdit;
   TEdit2: TEdit;
   TLabel1: TLabel;
 end;
 

Die für die Klassenutzer wichtigen "public"-Elemente sind nun alle zu Beginn der Klasse aufgeführt und von den Interna klar getrennt.

Das ist ja jetzt auch schon gegeben, wenn die Methoden in "private" definiert werden. Wo ist das Problem?

Das Problem liegt darin dass die "public" properties nicht am Beginn der Klasse angeordnet sind wo die IDE mit Code-Navigation hinspringt und wo sie für Anwender der Klasse am besten sichtbar sind.

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: "forward" property Felder/getter/setter?

Beitrag von pluto »

Bitte zeige auch noch die Verwendung der Klassen. Ich sehe nicht, was du erreichen willst.

Ich dachte das wäre klar:

Code: Alles auswählen

TPLBaseCSS_Color.value:=StrCSSToColor(Token);

Es geht in diesen Beispiel darum, ein CSS Parser zu erstellen.
In dem erstelle ich ein Token. Der Token kann nun je nach Eigenschafts Name, natürlich eine andere Bedeutung haben.

Z.B. color:red
wäre eine CSS Eigenschaft die ein Farb Speichert.

Schreibst du in einer Form auch "published" zu Beginn?

eher selten. Das meiste macht sowieso bei mir die IDE.

Das Problem liegt darin dass die "public" properties nicht am Beginn der Klasse angeordnet sind wo die IDE mit Code-Navigation

Wenn ich auf eine Eigenschaft Klicke, wird da hingesprungen, wo sie definiert ist. Ist doch alles richtig?
MFG
Michael Springwald

braunbär
Beiträge: 369
Registriert: Do 8. Jun 2017, 18:21
OS, Lazarus, FPC: Windows 10 64bit, Lazarus 2.0.10, FPC 3.2.0
CPU-Target: 64Bit
Wohnort: Wien

Re: "forward" property Felder/getter/setter?

Beitrag von braunbär »

Meines Erachtens wäre das durchaus sinnvoll ("forward" bei getter/Setter), aber im Grunde genommen nicht wirklich wichtig. Generell sind all diese Einschränkungen im ursprünglichen Pascal (Deklarieren vor - fast - jeder Verwendung, gegebenenfalls forward-Deklarationen, Klassen gab es ja noch nicht) wohl nicht einem Wunsch nach "Ordnung" geschuldet, sondern eher dem Wunsch, mit den damals verfügbaren Rechenleistungen mit vernünftigem Aufwand einen halbwegs flotten Compiler zu basteln. Das nennt man auch "aus der Not eine Tugend machen". Forward Deklarationen könnte man komplett kübeln, die bringen für den Anwendungsprogrammierer keinen Vorteil, und die Compilerbauer sollten heute mit der zusätzlichen Anforderung schon irgendwie zu Rande kommen.

Ist halt Geschmackssache, wie weit du dich von der ursprünglichen Sprache Object Pascal entfernen willst. Was mich abschreckt, ist deine Absicht, keine impliziten Typumwandlungen zuzulassen, und deine Ablehnung von Generics. Das ist meiner Meinung nach eine echte Verschlechtbesserung gegenüber dem heutigen Object Pascal und bringt ganz sicher keinen Produktivitätsgewinn. Den ? Operator würde ich dagegen auch für eine gute Sache halten, der fehlt mir in Pascal.

pluto hat geschrieben:Es sieht einfach nicht richtig aus. Auch wenn es Logisch(nun weiß ich es) eher hinkommt(Weil wir den Code von Vorne nach Hinten lesen).

Das ist kein taugliches Argument. "richtig" siehr es für dich nur deshalb nicht aus, weil du es anders gewöhnt bist. Gewohnheit sollte man bei der Definition von Neuem hintan stellen. Die Reihenfolge vertauschen zu können bringt jedenfalls, selbst wenn es keine großen Vorteile gibt, ganz sicher keinen Nachteil.
Möglichst weitgehende (Abwärts)Kompatibilität ist allerdings auch bei eine neuen Sprache sinnvoll: je ähnlicher die Sprachen sind, desto weniger muss man umdenken, wenn man zwischen den Sprachen wechseln muss. Denn die Erwartung, dass MSELang zum weltweiten Programmierstandard werden könnte, ist wahrscheinlich etwas zu optimistisch. :wink:

Antworten