"forward" property Felder/getter/setter?

Forum für alles rund um die MSEide und MSEgui

"forward" property Felder/getter/setter?

Beitragvon mse » 30. Jun 2017, 16:24 "forward" property Felder/getter/setter?

MSElang erlaubt die Definition von properties vor der Definition der zugehörigen Felder/getter/setter. Der Hintergrund ist, dass es für die Anwender des Objekts oder der Klasse bequemer ist, die "public" Elemente am Anfang der Definition zu sehen.
Code: Alles auswählen
 
type
 cbase = class() [virtual]
  destructor destroy() [virtual];
 end;
 
 cexception = class(cbase) //default visibility is "public"
  constructor create(const message: string8);
  property message: string8 read fmessage write fmessage;
 
  protected
   fmessage: string8;
 end;
 

statt
Code: Alles auswählen
 
 cexception = class(cbase) //default visibility is "public"
  protected
   fmessage: string8;
  public
   constructor create(const message: string8);
   property message: string8 read fmessage write fmessage;
 end;
 


Was meint ihr dazu?
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon marcov » 30. Jun 2017, 17:16 Re: "forward" property Felder/getter/setter?

Nutzen bevor Definition? "UnWirthlich". :(
marcov
 
Beiträge: 999
Registriert: 5. Aug 2008, 08:37
Wohnort: Eindhoven (Niederlande)
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk) | 
CPU-Target: 32/64,PPC(+64), ARM
Nach oben

Beitragvon mse » 1. Jul 2017, 06:31 Re: "forward" property Felder/getter/setter?

Meine Maxime ist Produktivität. Gibt es weitere Argumente?
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon theo » 1. Jul 2017, 09:05 Re: "forward" property Felder/getter/setter?

@mse: Deine Vorstellungen von Produktivität kann ich meistens nicht nachvollziehen.

Ich nehme an, JQuery ist für dich das Ideal:

Code: Alles auswählen
$("#divTest2").text("Hello, world!").removeClass("blue").addClass("bold").css("color", "blue").slideUp(2000).slideDown(2000);


Müsste man natürlich für dich alles noch lowercasen, damit es noch "übersichtlicher" wird. :wink:

:lol:
theo
 
Beiträge: 7895
Registriert: 11. Sep 2006, 18:01

Beitragvon mse » 1. Jul 2017, 10:00 Re: "forward" property Felder/getter/setter?

theo hat geschrieben:Ich nehme an, JQuery ist für dich das Ideal:

Code: Alles auswählen
$("#divTest2").text("Hello, world!").removeClass("blue").addClass("bold").css("color", "blue").slideUp(2000).slideDown(2000);


Nein:
https://www.mail-archive.com/mseide-mse ... 11129.html
Ich vermisse deine Argumente für oder gegen die Möglichkeit properties vor den getter()/setter()/Felder zu definieren.
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon theo » 1. Jul 2017, 10:18 Re: "forward" property Felder/getter/setter?

Bin kein Sprachhygieniker, aber es ist eine Veränderung der gewohnten Reihenfolge ohne für mich erkennbaren Vorteil.
In Code Insight von Lazarus werden private und ggf. protected Felder sowieso ausgeblendet.
Für meine Arbeitsweise bringt es afaics nichts außer Verwirrung.

Aber MSElang ist ja dein Projekt, da kannst du natürlich machen was du für richtig hältst.
theo
 
Beiträge: 7895
Registriert: 11. Sep 2006, 18:01

Beitragvon mse » 1. Jul 2017, 11:58 Re: "forward" property Felder/getter/setter?

Meiner Meinung nach sollte eine Programmiersprache so konstruiert sein, dass sie auch ohne Hilfsfunktionen einer IDE gut erfassbar ist. In einer Pascal Prozedur schaut man auch zuoberst nach den Variablen, warum soll das nicht in Klassendefinitionen gleich gehandhabt werden? Ist die Nachbarschaft von Klassen-Kopf und öffentlichen Eigenschaften keine gute Sache? Mit dem Argument "verwirrend da ungewohnt" wird jeder Fortschritt unmöglich gemacht.
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon theo » 1. Jul 2017, 12:10 Re: "forward" property Felder/getter/setter?

Ich sehe das so: "Veränderungen sind grundsätzlich schlecht, außer sie bringen einen Vorteil." :wink:
Da ich nie mit Notepad Pascal Programme schreibe, erkenne ich für mich keinen Vorteil.

Aber vielleicht gibt es dazu noch andere Meinungen. Mir ist diese Sache nicht so wichtig, dass ich dafür oder dagegen kämpfen würde.
theo
 
Beiträge: 7895
Registriert: 11. Sep 2006, 18:01

Beitragvon marcov » 1. Jul 2017, 12:30 Re: "forward" property Felder/getter/setter?

mse hat geschrieben:Meine Maxime ist Produktivität. Gibt es weitere Argumente?


Meine Maxim auch, aber vielleicht mehr von ein mehr praxisnaher Gesichtspunkt.

Nutzung bevor Deklaration ist komplizierter, speziell in für gezielter Warnungen und andere Fehler. Wie viele Unittests hast du für Fehler generation?

Produktivität verbesserung durch Sprache Mikrooptimalization von Syntax ist kaum zu messen.

Wenn man wirklich etwas am Produktivität tun will, kann man am besten nur an Open Source Debugger arbeiten, weil es dort die verschiedene OSS Suites meiner Sichtens nach am meisten mangelt.

Und auch ich denke das man nichts in Sprache hineinstecken soll was man in IDE abdecken kann.
marcov
 
Beiträge: 999
Registriert: 5. Aug 2008, 08:37
Wohnort: Eindhoven (Niederlande)
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk) | 
CPU-Target: 32/64,PPC(+64), ARM
Nach oben

Beitragvon Bitschubser » 1. Jul 2017, 12:36 Re: "forward" property Felder/getter/setter?

marcov hat geschrieben:Nutzen bevor Definition? "UnWirthlich". :(


Philosophisch gesehen hast du recht - aber wirklich 100% durchzuhalten war das Konzept ja prinzipiell von vorne herein nicht - siehe Notwendigkeit von „forward“ und noch viel direkter:

PMeinTyp = ^TMeinTyp;
TMeinTyp = …

Also muss man meiner Meinung nach bei jeder Ausnahme überlegen, ob die nötig ist oder echte Vorteile bringt.

Wenn ich mal eine Programmiersprache entwerfen sollte dann werde ich gleich 3 Schritte weitergehen und die Klassendeklaration aufsplitten:

public, published… in “interface“
protected, private… in “implementation”

- das hätte gleichzeitig den Vorteil, dass Typen und Konstanten die ich nur für private Sachen in der Klasse brauche nicht im “interface“ sichtbar rumliegen müssen.
Bitschubser
 
Beiträge: 61
Registriert: 27. Aug 2012, 14:43

Beitragvon marcov » 1. Jul 2017, 13:31 Re: "forward" property Felder/getter/setter?

Bitschubser hat geschrieben:
marcov hat geschrieben:Nutzen bevor Definition? "UnWirthlich". :(


Philosophisch gesehen hast du recht - aber wirklich 100% durchzuhalten war das Konzept ja prinzipiell von vorne herein nicht


Stimmt. Aber die datieren meist auch von bevor Overloading hinzugefügt ist, wodurch es mehr Ambiguität gibt. (Selber Identifier, unterschiedlicher Meinung/signature)

Also muss man meiner Meinung nach bei jeder Ausnahme überlegen, ob die nötig ist oder echte Vorteile bringt.


Genau.

Wenn ich mal eine Programmiersprache entwerfen sollte dann werde ich gleich 3 Schritte weitergehen und die Klassendeklaration aufsplitten:

public, published… in “interface“
protected, private… in “implementation”

- das hätte gleichzeitig den Vorteil, dass Typen und Konstanten die ich nur für private Sachen in der Klasse brauche nicht im “interface“ sichtbar rumliegen müssen.


Man kann solche Dingen nicht separieren von wie es Unit System arbeitet. Damit muss eine andere Unit mit Klasse arbeiten die nicht ganz definiert sind. Also muss man möglich doch Implementation und Interface jedes mal scannen
marcov
 
Beiträge: 999
Registriert: 5. Aug 2008, 08:37
Wohnort: Eindhoven (Niederlande)
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk) | 
CPU-Target: 32/64,PPC(+64), ARM
Nach oben

Beitragvon mse » 1. Jul 2017, 14:21 Re: "forward" property Felder/getter/setter?

marcov hat geschrieben:Nutzung bevor Deklaration ist komplizierter, speziell in für gezielter Warnungen und andere Fehler.

Du meinst Mehraufwand im Compiler? Das ist keine Begründung um eine bessere Sprachstruktur zu verhindern.
MSElang parst die property Elemente mitsamt ihren source-Referenzen in eine Struktur
Code: Alles auswählen
 
type
 identsourceinfoty = record
  ident: identty;
  source: sourceinfoty;
 end;
 identsourcevecty = record
  high: integer;
  d: array[0..maxidentvector] of identsourceinfoty;
 end;
 
 propfieldinfoty = record
  propele: elementoffsetty;
  propoffs: int32;
  idents: identsourcevecty;
 end;
 ppropfieldinfoty = ^propfieldinfoty;
 
 indexparaminfoty = record
  partype: elementoffsetty;
  parflags: addressflagsty;
 end;
 indexparamvecty = record
  high: int32;
  d: array[0..maxidentvector] of indexparaminfoty;
 end;
 
 resolvepropertyinfoty = record
  errorref: int32;
  propflags: propflagsty;
  typeele: elementoffsetty;
  indilev: int32;
  indexparams: indexparamvecty;
  readfield: propfieldinfoty;
  writefield: propfieldinfoty;
 end;
 presolvepropertyinfoty = ^resolvepropertyinfoty;
 

danach wird geprüft, ob der accessor bereits deklariert ist
Code: Alles auswählen
 
function resolvepropaccessor(var resinfo: resolvepropertyinfoty;
                                              const awrite: boolean): boolean;
[...]
begin
 result:= false;
 if awrite then begin
  field:= @resinfo.writefield;
 end
 else begin
  field:= @resinfo.readfield;
 end;
 hasindex:= resinfo.indexparams.high >= 0;
 with resinfo,field^ do begin
  elekind1:= ele.findcurrent(idents.d[0].ident,[],[vik_ancestor],po1);
  ele1:= ele.eledatarel(po1);
  case elekind1 of
   ek_none: begin
    if awrite then begin
     fla1:= pof_writeforward;
    end
    else begin
     fla1:= pof_readforward;
    end;
    if fla1 in propflags then begin
     identerror(idents.d[0].source,idents.d[0].ident,err_identifiernotfound);
    end
    else begin
     include(propflags,fla1);
    end;
   end;
[...]
 

falls nicht wird die property in eine Liste eingetragen und resolvepropacessor() am Ende der Klassendefinition nochmals aufgerufen.
Code: Alles auswählen
 
 
procedure handleclassproperty();
[...]
     if resinfo^.propflags * [pof_readforward,pof_writeforward] <> [] then begin
      with pclasspendingitemty(
                       addlistitem(pendingclassitems,
                                   forwardpropchain))^ do begin
       forwardprop.resinfo:= getsegmentoffset(seg_temp,resinfo);
       forwardprop.propele:= ele.eledatarel(po1);
      end;
     end
     else begin
      updateprop(resinfo^,po1);
      setsegmenttop(seg_temp,resinfo);
     end;
[...]
 
procedure resolveforwardprop(var item);
var
 p1: presolvepropertyinfoty;
begin
 with classpendingitemty(item).forwardprop do begin
  p1:= getsegmentpo(seg_temp,resinfo);
  if pof_readforward in p1^.propflags then begin
   resolvepropaccessor(p1^,false);
  end;
  if pof_writeforward in p1^.propflags then begin
   resolvepropaccessor(p1^,true);
  end;
  updateprop(p1^,ele.eledataabs(propele));
 end;
end;
 
procedure handleclassdefreturn();
[...]
  resolvelist(pendingclassitems,@resolveforwardprop,forwardpropchain);
 
 

Die Möglichkeiten zur Fehlerbehandlung sind beide mal die gleichen.
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon mse » 1. Jul 2017, 14:31 Re: "forward" property Felder/getter/setter?

Bitschubser hat geschrieben:Wenn ich mal eine Programmiersprache entwerfen sollte dann werde ich gleich 3 Schritte weitergehen und die Klassendeklaration aufsplitten:

public, published… in “interface“
protected, private… in “implementation”

- das hätte gleichzeitig den Vorteil, dass Typen und Konstanten die ich nur für private Sachen in der Klasse brauche nicht im “interface“ sichtbar rumliegen müssen.

Wie Marco schreibt hat das den grossen Nachteil, dass dann "interface" und "implementation" nicht unabhängig voneinander kompiliert werden können, da im "interface" nicht genügend Informationen vorhanden sind um die Klasse zu verwenden. Z.B. sind die Strukturgrösse und die Feldadressen noch nicht bekannt.
Dass die gesamte Klassendefinition an einem Ort ist, hat auch Vorteile. Das Problem, dass die wichtigsten Definitionen am Schluss sind hat MSElang ja gelöst. ;-)
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon marcov » 1. Jul 2017, 16:40 Re: "forward" property Felder/getter/setter?

mse hat geschrieben:
marcov hat geschrieben:Nutzung bevor Deklaration ist komplizierter, speziell in für gezielter Warnungen und andere Fehler.

Du meinst Mehraufwand im Compiler? Das ist keine Begründung um eine bessere Sprachstruktur zu verhindern.
MSElang parst die property Elemente mitsamt ihren source-Referenzen in eine Struktur


Und wie funktioniert das wenn es Fehler nach eine undefinierte Identifier gibt ?
marcov
 
Beiträge: 999
Registriert: 5. Aug 2008, 08:37
Wohnort: Eindhoven (Niederlande)
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk) | 
CPU-Target: 32/64,PPC(+64), ARM
Nach oben

Beitragvon mse » 1. Jul 2017, 17:57 Re: "forward" property Felder/getter/setter?

marcov hat geschrieben:Und wie funktioniert das wenn es Fehler nach eine undefinierte Identifier gibt ?

Dann wird eine Fehlermeldung ausgegeben, siehe oben:
Code: Alles auswählen
 
   if fla1 in propflags then begin
    identerror(idents.d[0].source,idents.d[0].ident,err_identifiernotfound);
   end
 

Vielleicht verstehe ich die Frage nicht?
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

» Weitere Beiträge siehe nächste Seite »
Nächste

Zurück zu MSEide und MSEgui



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

porpoises-institution
accuracy-worried