"forward" property Felder/getter/setter?

Forum für alles rund um die MSEide und MSEgui
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

"forward" property Felder/getter/setter?

Beitrag von mse »

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?

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 »

Nutzen bevor Definition? "UnWirthlich". :(

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 »

Meine Maxime ist Produktivität. Gibt es weitere Argumente?

Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

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

Beitrag von theo »

@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:

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 »

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.

Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

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

Beitrag von theo »

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.

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 »

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.

Benutzeravatar
theo
Beiträge: 10467
Registriert: Mo 11. Sep 2006, 19:01

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

Beitrag von theo »

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.

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 »

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.

Bitschubser
Beiträge: 61
Registriert: Mo 27. Aug 2012, 15:43

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

Beitrag von Bitschubser »

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.

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 »

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

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 »

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

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. ;-)

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 »

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 ?

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 »

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?

Antworten