Übergabeparameter bei prozeduren

[mintpc]

Hallo zusammen,

bei Delphi können globale Variablen und Übergabevariablen in Prozeduren gleichen Namen haben.

Beispiel:

Code: Alles auswählen

type
  TKlasse = class
     Beschreibung : String;
     Norden, Sueden, Westen, Osten : TKlasse;
     procedure referenziere_selbst (norden, osten, sueden, westen : TKlasse); 
  end;

Lazarus meckert die doppelten Variablennamen an. Offensichtlich geht das also nicht mehr.
Warum?

Danke vielmals

mintpc

[Keifor]

Der Compiler (FPC) kennt mehrere Sprachvarianten von Pascal.
Lazarus stellt diese per Standard auf OBJFPC ein durch die Compiler Direktive

{$mode objfpc} im Kopf der Unit/des Programmes.
Einfach zu {$mode delphi} abändern und es sollte entsprechende Delphi Syntax erlauben.

Mehr infos dazu unter: http://www.freepascal.org/docs-html/pro ... 00001.2.16" onclick="window.open(this.href);return false;

[Scotty]

Geht das wirklich, eine sich selbst referenzierende Klasse? Und wozu sollte dies gut sein?
(TKlasse=class... Norden:TKlasse)

[Keifor]

Ja, das geht. Ob Delphi Mode oder OBJFPC Mode ist dabei egal. Die Grundfrage war, warum Parameternamen nicht den gleichen Namen wie Instanzvariablen (Variablen der Klasse) haben dürfen. Das wird in OBJFPC nicht erlaubt mit Begründung: es ist schlechte Praxis (fördert Verwechslungen z.B.)

Warum eine Klasse sich sich selbst Referenzieren kann wozu das nützlich ist, ist ein anderes Thema, allerdings hab ich mal fix was dazu geschrieben:

Es ist nicht das gleiche wie eine Struktur.
Bspw.

Code: Alles auswählen

TMyRecord = record
  a: TRecord;
end;

geht nicht, da TMyRecord noch nicht deklariert ist bis zum Ende der Deklaration.

Code: Alles auswählen

TMyClass = class
  FRef: TMyClass;
end;

geht, da FRef eh nur eine Referenz ist. Sozusagen ein Zeiger auf Objekte des bis dato noch nicht kompletten Typen TMyClass.

Praktischen nutzen hat das Bspw. in verschiedenen Entwurfsmustern.
Beispiel:

Code: Alles auswählen

TAbstractProxy = class
   FNextProxy: TAbstractProxy;
   function proxyCall( cmd: String ): Boolean; virtual;
   function assignNext( AProxy: TAbstractProxy ): Boolean;
   ...

So kann man z.B. von TAbstractProxy Klassen ableiten die einen "Befehl" auf unterschiedliche Art weiterreichen. Bspw. eine Klasse die Befehle an Clients sendet, oder an andere Komponenten oder...

[mintpc]

Hallo nochmal,

danke für die schnelle Antwort und Erklärung.

Zu dem Sinn der Selbstreferenzierung: Ich bin Lehrer und lasse
als Einstieg in die Objektorientierung gerne ein "Textadventure" schreiben.
Jeder betretbare Raum ist erstmal eine Instanz einer Klasse "TRaum" und
die möglichen Ausgänge (man will sich ja von Raum zu Raum bewegen)
sind Referenzen auf andere Instanzen derselben Klasse.

Klingt komisch, macht den Schülern aber Spaß.

Und der Vorteil als Einstieg ist, dass mit einer einzigen sehr einfachen Klasse
ein ganzes umfangreiches Spiel geschrieben werden kann.

Also, nochmals danke für die Hinweise.

mintpc

[theo]

Das wird in OBJFPC nicht erlaubt mit Begründung: es ist schlechte Praxis (fördert Verwechslungen z.B.)

Ja, ich würde dir auch empfehlen, dich an die Benennungsregeln zu halten und die Sichtbarkeit reinzuschreiben.
Das vereinfacht die Lesbarkeit ungemein, auch für andere.
z.B.

Code: Alles auswählen

type
  TKlasse = class
   private
     fBeschreibung : String;
     fNorden, fSueden, fWesten, fOsten : TKlasse;
   public
     procedure referenziere_selbst (norden, osten, sueden, westen : TKlasse); 
  end;

Also immer "f" für Feld.

Ein Property heisst dann immer ohne "f"

z.B.
property Norden: TKlasse read fNorden write SetNorden;

[Socke]

Code: Alles auswählen

procedure referenziere_selbst (norden, osten, sueden, westen : TKlasse);

[...]
property Norden: TKlasse read fNorden write SetNorden;

Damit hätten aber "Norden" (Eigenschaft) und "norden" (Parameter) wieder den selben Namen. Daher hängt man bei Parametern oft ein "a" oder einen anderen Präfix davor (aValue/AValue/TheOwner).
In Deutsch wäre das dann in etwa: EinNorden, EinOsten, EinSueden, EinWesten: TKlasse) (wobei man EinNorden nicht mit einnorden verwechseln sollte ).

Übrigens: TKlasse ist auch kein Optimaler Name. Dass TKlasse eine Klasse im objektorientierten Sinne ist sehen wir an der Deklaration.

[pluto]

Ich frage mich gerade wie der Compilier unterschiedet ob jetzt eine Variable in der Paramenter liste genutzt werden soll oder von der Klasse selbst, wenn sie gleich klingen.

und wie möchtest du die Zuweisung machen ?
test:=test ?
das macht doch wenig Sinn *G*.....

Die OOP ist eine feine Sache, wenn SIE RICHTIG angewendet wird *G*......

[Socke]

Ich frage mich gerade wie der Compilier unterschiedet ob jetzt eine Variable in der Paramenter liste genutzt werden soll oder von der Klasse selbst, wenn sie gleich klingen.

Sowas nennt sich Sichtbarkeit. Der innere Block überschreibt immer den äußeren. Daher gilt (so weit ich denke):
Lokale Variablen -> Prozedur-Parameter -> Instanzvariablen (Felder) -> Globale Variablen
Ein Zugriff auf verdeckte Elemente kann ich mir nur über einen mehr qualifizierenden Namen vorstellen: also <unit>.<var>/<objekt>.<feld>

[pluto]

Ich kann mir sowas einfach nicht vorstellen. So kann man doch kein Zugang zu den Glaobeln Variablen erlangen und auch keinen zu den Parametern. Meiner Meinung. Es würde nur eins von beiden gehen.

[Teekeks]

So kann man doch kein Zugang zu den Glaobeln Variablen erlangen

doch, über unit.var

[pluto]

doch, über unit.var

Ach so, dass ist also der "Trick"....

[Socke]

doch, über unit.var

Hab ich das nicht so geschrieben oder kann ich nicht mehr lesen ?
Das Zauberwort heißt übrigens "voll qualifizierender Name".

[Teekeks]

Ja, das hast du so geschrieben, aber da pluto das scheinbar nicht gesehen hatte, habe ich es einfach mal wiederholt.

[lrlr]

Geht das wirklich, eine sich selbst referenzierende Klasse? Und wozu sollte dies gut sein?
(TKlasse=class... Norden:TKlasse)

> Und wozu sollte dies gut sein?

in diesem fall, keine ahnung, aber

bei "jedem" baum hast du das (als referenz auf Parent z.b. )

TMenuItem.Parent

ist z.b. ein TMenuItem