"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 »

Den ? Operator würde ich dagegen auch für eine gute Sache halten, der fehlt mir in Pascal.

Das war Ironisch gemeint. Dann hätten wir das gleiche Probleme wie in C:
dass in Vergleichen Zuweisungen möglich sind. Das hat der ESA schon eine Arine5 Rakete gekostet.

Es gibt fälle, wo der natürlich Sinnvoll wäre..... Dann müsste man ihn nur anders umsetzten.

Ist halt Geschmackssache, wie weit du dich von der ursprünglichen Sprache Object Pascal entfernen willst.

Ich glaube das ist der Punkt um den es eigentlich hier geht. Es bringt kaum Vorteile.
Die IDE Code Navigation tut bei mir genau das was ich auch erwarte.

wohl nicht einem Wunsch nach "Ordnung" geschuldet, sondern eher dem Wunsch

Aber es hat Praktische Grenzen gesetzt finde ich. Das ist halt der Unterschied zwischen C und Pascal. Die Ordnung.

keine impliziten Typumwandlungen zuzulassen

Kannst du ein kurzes Beispiel geben, was das genau ist? Ist das eine "Direkte" Umwandlung wie StrToInt?
MFG
Michael Springwald

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

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

Beitrag von wp_xyz »

braunbär hat geschrieben:Den ? Operator würde ich dagegen auch für eine gute Sache halten, der fehlt mir in Pascal.

Es gibt IfThen, und das ist tausend mal verständlicher:

Code: Alles auswählen

uses
  math;
...
  y := IfThen(x > 0, 1, 2);
 
  y := x > 0 ? 1, 2;

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:Ich dachte das wäre klar:

Code: Alles auswählen

TPLBaseCSS_Color.value:=StrCSSToColor(Token);


"TPLBaseCSS_Color" ist doch ein Klassentyp? Meinst du eine globale Variable welche nur in Instanzen von "TPLBaseCSS_Color" und Nachkommen sichtbar ist?
Bitte mache ein komplettes Beispiel. Natürlich könnte ich mir anhand der Aufgabenstellung vorstellen, was du meinen könntest. Leider kommt es häufig vor, dass man sich in der Meinung, was die Gesprächspartner meinen, irrt. Das würde ich gerne vermeiden.
Schreibst du in einer Form auch "published" zu Beginn?

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

Die schreibt kein "published" AFAIK.
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?

Wenn du auf "TPLBaseCSS_Color" klickst wird auf den Beginn der Definition gesprungen.

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 »

braunbär hat geschrieben:Was mich abschreckt, ist deine Absicht, keine impliziten Typumwandlungen zuzulassen,

Durch implizite Typumwandlungen gibt es schwierig zu erkennende Fehler in Ausdrücken. Es ist noch nicht in Stein gemeisselt, wie im Wiki geschrieben, es geht vorerst um Experimente. Die Zielsetzung von MSElang ist allerdings klar.
und deine Ablehnung von Generics.

Wenn man Generics richtig machen will, geht die Sprachkomplexität schnell in Richtung C++ und das entspricht nicht den Zielen von MSElang. Die RTL wird Elemente enthalten, welche zusammen mit speziellen Compilereigenschaften Generics entbehrlich machen.

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 »

IfThen

Den kannte ich jetzt noch nicht. Stimmt es ist auf jedenfall verständlicher.

"TPLBaseCSS_Color" ist doch ein Klassentyp? Meinst du eine globale Variable welche nur in Instanzen von "TPLBaseCSS_Color" und Nachkommen sichtbar ist?

Genau. Ich mein keine Variable sondern ein Klassen Feld wie ein Property. Dieses soll in allen Nachkommen Sichtbar sein. Jedoch mit unterschiedlichen Datentypen.

Bitte mache ein komplettes Beispiel. Natürlich könnte ich mir anhand der Aufgabenstellung vorstellen, was du meinen könntest. Leider kommt es häufig vor, dass man sich in der Meinung, was die Gesprächspartner meinen, irrt. Das würde ich gerne vermeiden.

Ich überlegt mir was passendes. Ich hatte gehofft das es reicht, wenn man es beschreibt.
Du brauchst in Prinzip nur an CSS zu denken und wie du ein Parser dafür erstellen würdest. Dann kommst du Automatisch auf die "Idee".

Ich schau mal in meinen Projekt Ordner. Vielleicht finde ich was passendes.

Die schreibt kein "published" AFAIK.

Nein. Nicht am Anfang. Das schreibe ich am Ende.

Wenn du auf "TPLBaseCSS_Color" klickst wird auf den Beginn der Definition gesprungen.

Ja. Klicke ich auf eine Eigenschaft, wird zu dieser gesprungen.
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:Ich schau mal in meinen Projekt Ordner. Vielleicht finde ich was passendes.

Bitte schicke kein existierendes Projekt sondern mache ein vollständiges Beispiel mit der von dir gewünschten "forward property".

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 schicke kein existierendes Projekt sondern mache ein vollständiges Beispiel mit der von dir gewünschten "forward property".

Das habe ich ja schon gemacht. Ein Property als forward.
Praktisch wie bei einer Klasse. Nur innerhalb einer Klasse.

OK: Hier noch mal ein komplettes Beispiel:

Code: Alles auswählen

 
// Definition
  TPLCSS = class
  ...
  public
    property Value;forward;
    property Name:String;
 
   TPLCSSColor(TPLCSS)
   ...
   public
     property Value:TCSSColor read fValue write fValue; // Wurde voher als forward definiert.
 
// Anwendung
var
  PLCSS:TPLCSS;
  Token:String;
begin
  // CSS Token erstellen
  // Das mache ich jetzt mal nicht.
  PLCSS:=TPLCSSColor.Create;
  PLCSS.Value:=StringToCSSColor(Token)// Damit kann nun ein Wert zugewiesen werden.
 
// Anwendung II
Var
  PLCSS:TPLCSS;
begin
  writeln(PLCSS.Value);
end;
 


Der Vorteil wäre einfach: Man kann eine Basis Klasse erstelle in diesen Beispiel führ CSS.
Eine Klasse, die einen CSS Selector speichert. CSS kennt ja verschiedene Datentypen.

Nun könnte die Grund Klasse für CSS einfach aus zwei Eigenschaften bestehen:
Einmal Name von Typ String und einmal Value mit kein Typ sondern als forward.
In Etwa das gleiche hätte man, wenn man Value von Typ TObject hat.
Nur müsste man dann immer Casten. Um auf Value zugreifen zu können.
MFG
Michael Springwald

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

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

Beitrag von marcov »

Muss man so noch immer, weil TPLCSS.value noch immer nicht komplet definiert ist (kein Typ), und darum nicht genutzt kann worden.

Das Kompiler Typsystem weist einfach nicht das dein var PLCSS eigentlich ein TPLCSSColor 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 »

Muss man so noch immer, weil TPLCSS.value noch immer nicht komplet definiert ist (kein Typ), und darum nicht genutzt kann worden.

Naja, Nicht wenn man den Nachkommen nutzt:

Code: Alles auswählen

 
var
  PLCSS:TPLCSS;
begin
  PLCSS:=TPLCSSColor.Create;
end;
 

In diesen Fall weiß der Compiler ja was für ein Datentyp Value hat.

Das Kompiler Typsystem weist einfach nicht das dein var PLCSS eigentlich ein TPLCSSColor ist.

Doch, wenn man den Nachkommen nutzt.

Wenn ich StringList:TStrings nutze, ist es doch das gleiche?
Ich nutzte StringList:=TStringList.Create;
MFG
Michael Springwald

marcov
Beiträge: 1100
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

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

Beitrag von marcov »

pluto hat geschrieben:[
Wenn ich StringList:TStrings nutze, ist es doch das gleiche?
Ich nutzte StringList:=TStringList.Create;


Wenn man der Abgeleiteten Klasse nutzt ist die deklaration im Original Klasse egal. Und TStrings properties sind typiert (als "string") und kann man auch nutzen als der Variabelen der Typ "Tstrings" ist (aber mit TStringlist.create instantiert)

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 »

pluto hat geschrieben:
Den ? Operator würde ich dagegen auch für eine gute Sache halten, der fehlt mir in Pascal.

Das war Ironisch gemeint. Dann hätten wir das gleiche Probleme wie in C:
dass in Vergleichen Zuweisungen möglich sind.

1. Zuweisungen in Vergleichen wären manchmal sehr nützlich.
2. der ? Operator selbst ermöglicht keine Zuweisungen in Vergleichen. Wie soll das denn gehen?
3. Zuweisungen in Vergleichen sind über Seiteneffekte von Funktionsaufrufen in Pascal zwar nur umständlich machbar, aber prinzipiell auch jetzt schon möglich.

keine impliziten Typumwandlungen zuzulassen

Kannst du ein kurzes Beispiel geben, was das genau ist? Ist das eine "Direkte" Umwandlung wie StrToInt?

Nein, ich meine implizite Umwandlungen von integer nach real, byte zu integer etc.

mse hat geschrieben:Durch implizite Typumwandlungen gibt es schwierig zu erkennende Fehler in Ausdrücken.

Klar, es liegt immer in der Hand des Programmierers, Sprachfeatures vernünftig einzusetzen. Ein Sprachfeature zu streichen, weil Programmierer damit auch Mist machen können, halte ich generell für keine gute Idee. Mit Zeigern kann man grauenhaften Code mit schwierig zu erkennenden Fehlern produzieren, und auch mit goto kann man wirren, undurchschaubaren Code produzieren, wenn man es ohne Bedacht einsetzt. Würdet du deshalb Zeiger und goto abschaffen?

wp_xyz hat geschrieben:Es gibt IfThen, und das ist tausend mal verständlicher:

Das ist kein adäquater Ersatz für den Ternary Operator. IfThen ist eine Funktion, da werden zuerst beide Ausdrücke und der Vergleich ausgewertet und die Ergebnisse als Parameter übergeben.

Code: Alles auswählen

 
ch := length(s)>0 ? s[1] : '  ';
 

funktioniert bestens (würde, wenn es das gäbe), während

Code: Alles auswählen

 
ch := ifthen (length(s)>0, s[1],  '  ')
 

bei einem String der Länge 0 einen Ausnahmefehler produziert.
Abgesehen davon finde ich persönlich diese Schreibweise nicht verständlicher, sondern eher schwerfälliger - aber das ist wohl Geschmackssache. Die Bedingung ist beim ternary Operator durch die Syntax (das ?) deutlich auf den ersten Blick erkennbar von den Werten getrennt, während bei ifthen die Bedingung und die beiden bedingten Ausdrücke nicht so gut unterscheidbar nebeneinander als Parameter der Funktion dastehen.

mse hat geschrieben:Wenn man Generics richtig machen will, geht die Sprachkomplexität schnell in Richtung C++ und das entspricht nicht den Zielen von MSElang.

Sind die Generics von Delphi und von Free Pascal deiner Meinung nach nicht "richtig gemacht"? Ich finde nicht, dass die Sprache dadurch sehr viel komplexer wird.

mse hat geschrieben:Die RTL wird Elemente enthalten, welche zusammen mit speziellen Compilereigenschaften Generics entbehrlich machen.

Da bin ich gespannt... Aber irgendwie wird es doch auf eine Art einer Generics - Implementierung hinauslaufen müssen, auch wenn du es dann anders nennst, oder?

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:OK: Hier noch mal ein komplettes Beispiel:

Code: Alles auswählen

 
// Definition
  TPLCSS = class
  ...
  public
    property Value;forward;
    property Name:String;
 
   TPLCSSColor(TPLCSS)
   ...
   public
     property Value:TCSSColor read fValue write fValue; // Wurde voher als forward definiert.
 
// Anwendung
var
  PLCSS:TPLCSS;
  Token:String;
begin
  // CSS Token erstellen
  // Das mache ich jetzt mal nicht.
  PLCSS:=TPLCSSColor.Create;
  PLCSS.Value:=StringToCSSColor(Token)// Damit kann nun ein Wert zugewiesen werden.
 
// Anwendung II
Var
  PLCSS:TPLCSS;
begin
  writeln(PLCSS.Value);
end;
 

Ich glaube nicht dass das so funktionieren kann.

Code: Alles auswählen

 
// Definition
  TPLCSS = class
  ...
  public
    property Value;forward;
    property Name:String;
 
   TPLCSSColor(TPLCSS)
   ...
   public
     property Value:TCSSColor read fValue write fValue; // Wurde voher als forward definiert.
 
// Anwendung II
 
procedure test(PLCSS:TPLCSS);
begin
  writeln(PLCSS.Value)//was soll writeln() mit "property Value; forward;" machen?
end;
 
// Anwendung
var
  PLCSS:TPLCSS;
  Token:String;
begin
  // CSS Token erstellen
  // Das mache ich jetzt mal nicht.
  PLCSS:=TPLCSSColor.Create;
  PLCSS.Value:=StringToCSSColor(Token)// Damit kann nun ein Wert zugewiesen werden.
  test(plcss);
 

Was du brauchst ist ein Basistyp, der alle verwendeten Datentypen beschreibt und spezialisierte Nachkommen, welche die Datentypen implementieren. Siehe z.B. "tdbcol" und Nachkommen.
https://gitlab.com/mseide-msegui/mseide ... result.pas
Eine andere Option sind Variants. Die sind aber langsam.
https://www.freepascal.org/docs-html/cu ... 640003.7.1

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 »

braunbär hat geschrieben:
mse hat geschrieben:Durch implizite Typumwandlungen gibt es schwierig zu erkennende Fehler in Ausdrücken.

Klar, es liegt immer in der Hand des Programmierers, Sprachfeatures vernünftig einzusetzen. Ein Sprachfeature zu streichen, weil Programmierer damit auch Mist machen können, halte ich generell für keine gute Idee. Mit Zeigern kann man grauenhaften Code mit schwierig zu erkennenden Fehlern produzieren, und auch mit goto kann man wirren, undurchschaubaren Code produzieren, wenn man es ohne Bedacht einsetzt. Würdet du deshalb Zeiger und goto abschaffen?

Das ist nicht dasselbe. Bei impliziter Typumwandlung passieren Sachen, die man nicht sieht. Bei gotos und Pointern sieht man was passiert. Wie gesagt, ich muss das noch mehr ausprobieren um zu entscheiden, ob die Bequemlichkeit höher zu gewichten ist als die Sicherheit.
mse hat geschrieben:Wenn man Generics richtig machen will, geht die Sprachkomplexität schnell in Richtung C++ und das entspricht nicht den Zielen von MSElang.

Sind die Generics von Delphi und von Free Pascal deiner Meinung nach nicht "richtig gemacht"? Ich finde nicht, dass die Sprache dadurch sehr viel komplexer wird.

Mir reicht es. Bei Free Pascal kommt bei Generics auch jede Woche etwas weiteres hinzu...
mse hat geschrieben:Die RTL wird Elemente enthalten, welche zusammen mit speziellen Compilereigenschaften Generics entbehrlich machen.

Da bin ich gespannt... Aber irgendwie wird es doch auf eine Art einer Generics - Implementierung hinauslaufen müssen, auch wenn du es dann anders nennst, oder?

Ich bin auch gespannt, wir werden sehen. ;-)

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

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

Beitrag von m.fuchs »

braunbär hat geschrieben:1. Zuweisungen in Vergleichen wären manchmal sehr nützlich.

Warum?

braunbär hat geschrieben:Klar, es liegt immer in der Hand des Programmierers, Sprachfeatures vernünftig einzusetzen. Ein Sprachfeature zu streichen, weil Programmierer damit auch Mist machen können, halte ich generell für keine gute Idee. Mit Zeigern kann man grauenhaften Code mit schwierig zu erkennenden Fehlern produzieren, und auch mit goto kann man wirren, undurchschaubaren Code produzieren, wenn man es ohne Bedacht einsetzt. Würdet du deshalb Zeiger und goto abschaffen?

GOTO auf alle Fälle, das ist unnötig. Es gibt ja immerhin schon einen Compilerschalter der es verbietet.

braunbär hat geschrieben:

Code: Alles auswählen

 
ch := length(s)>0 ? s[1] : '  ';
 

funktioniert bestens

Und ist unleserlich.

Und auch hier wieder meine Frage: was hast du gegen die Programmierung in C wenn du sowas in Pascal haben möchtest?
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

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 »

m.fuchs hat geschrieben:
1. Zuweisungen in Vergleichen wären manchmal sehr nützlich.

Warum?

Weil es einem manchmal ersparen würde, den exakt gleichen Programmcode zwei mal zu schreiben. Damit wird ein Programm immer besser lesbar und besser wartbar.
Und auch, wenn man über diese Frage geteilter Meinung sein kann, sind die Punkte 2 und 3 wohl unstrittig.

m.fuchs hat geschrieben:GOTO auf alle Fälle, das ist unnötig. Es gibt ja immerhin schon einen Compilerschalter der es verbietet.

Die Diskussion hier erneut zu führen ist müßig. Es gibt Fälle, in denen ein Programm durch die Verwendung von goto viel lesbarer wird als mit mühseligen und undurchsichtigen Goto-Umgehungskonstrukten mit Hilfe von boolean Variablen. Zwar könnte man die meisten dieser Fälle leicht ohne goto abdecken, wenn es ein Sprachkonstrukt zum Verlassen von verschachtelten Schleifen geben würde (das wäre wünschenswert), aber leider auch nicht alle.

m.fuchs hat geschrieben:Und ist unleserlich.

Es ist, wie ich oben begründet habe, BESSER leserlich: Bei ifthen stehen die Bedingung und die beiden Alternativausdrücke gleichberechtigt auf der gleichen Ebene als Funktionsparameter nebeneinander, während der ternäre Operator die Semantik des Befehls unmittelbar sichtbar macht. "Unleserlich" erscheint es dir nur, weil es für dich ungewohnt ist, aber das Argument kann nicht zählen, wenn es um die Beurteilung von etwas Neuem, und deshalb zwangsläufig ungewohnten, geht.
Dass bei Verwendung von IfThen immer beide Zweige ausgewertet werden, disqualifiziert das Konstrukt meines Erachtens komplett, ich verwende das prinzipiell gar nicht mehr, nachdem ich schon mehrmals unbedachter Weise über Laufzeitfehler wie den im oberen Post aufgezeigten gestolpert bin. Das ist eine unnötige Fehlerquelle.


m.fuchs hat geschrieben:Und auch hier wieder meine Frage: was hast du gegen die Programmierung in C wenn du sowas in Pascal haben möchtest?

Sehr viel. Einige wenige sinnvolle Features, die es in C gibt, wären aber in Pascal wünschenswert. Nicht alles, was es in C gibt, ist des Teufels.

mse hat geschrieben:Durch implizite Typumwandlungen gibt es schwierig zu erkennende Fehler in Ausdrücken.

Mir fällt eigentlich kein Beispiel ein, in der die Umwandlung von einem schmäleren in einen "breiteren" Datentyp zu schwierig zu erkennenden Fehlern führt. Die Gegenrichtung ist auch jetzt entweder gar nicht implizit möglich (real->integer), passiert nie innerhalb der Berechnung von Ausdrücken, sondern nur bei Zuweisungen (da sollte sich der Programmierer aber wirklich im Klaren darüber sein, welchen Wert er welcher Variablen zuweist), oder löst, zumindest in Delphi, eine Compilerwarnung aus (z.B. integer -> Byte oder char -> ansichar)
Zuletzt geändert von braunbär am Di 4. Jul 2017, 15:05, insgesamt 2-mal geändert.

Antworten