Sichtbarkeit von Objekt-Elementen

[Socke]

Hallo,
Ich habe hier einen Sachverhalt, den ich so nicht ganz verstehe...
[quote=Language-Reference-Guide]Private
All fields and methods that are in a private block, can only be accessed in the module (i.e. unit or program) that contains the object definition. They can be accessed from inside the object’s methods or from outside them e.g. from other objects’ methods, or global functions.
Protected
Is the same as Private, except that the members of a Protected section are also accessible to descendent types, even if they are implemented in other modules.
Public
fields and methods are always accessible, from everywhere. Fields and methods in a public section behave as though they were part of an ordinary record type.[/quote]
Demnach wäre ein Feld, das als private deklariert ist, in einem anderen Modul nicht sichtbar - auch nicht von einer abgeleiteten Klasse.
Jetzt habe ich aber etwas ausprobiert:

Code: Alles auswählen

unit contnrs;
...
  TOrderedList = class(TObject)
  private
    FList: TList;
  ...
  end;
...

Code: Alles auswählen

unit myunit;
uses contnrs;
type
  TPublicQueueList = class(TQueue)
  public
    property List: TList read FList;
  end;
...

Das ganze lässt sich wunderbar kompilieren. In Methoden kann ich auf FList aber nicht zugreifen.

Habe ich jetzt einfach etwas nicht richtig verstanden, oder bezieht sich das nicht sichtbar nur auf die Implementation (und nicht auch auf die Deklaration)?
Bitte um Aufklärung.

[theo]

Wenn ich das richtig sehe, ist das ein Bug und zwar ein etwas peinlicher
Ab in den Tracker damit http://bugs.freepascal.org/view_all_bug_page.php" onclick="window.open(this.href);return false;

[Scotty]

Ich hätte genau dieses Verhalten erwartet. Das Objekt erbt alle Eigenschaften und kann die natürlich nach Belieben publizieren. Wenn dort noch write FList; stünde, sollte ein "Zugriff" auf List auch möglich sein. Lesen hätte Socke schon ohne write können.

[theo]

@Scotty: Imo ist das ein Fehler.
Worin würde denn nach deiner Theorie der Unterschied zw. private und protected bestehen?

[Scotty]

Gutes Argument. Interessanterweise kann man das private-Statement auch anders umgehen: http://bugs.freepascal.org/view.php?id=14534" onclick="window.open(this.href);return false;

[pluto]

Genau das habe ich auch schon in meinen Klassen beobachtet: Ich kann auf variablen zu greifen die im Private Bereich sind, wenn ich von diesen Klassen ableite. Ich meine das ging nur in der gleichen Unit.

Worin würde denn nach deiner Theorie der Unterschied zw. private und protected bestehen?

Das habe ich mich dann auch an dieser stelle gefragt *G*

[Socke]

Genau das habe ich auch schon in meinen Klassen beobachtet: Ich kann auf variablen zu greifen die im Private Bereich sind, wenn ich von diesen Klassen ableite. Ich meine das ging nur in der gleichen Unit.

Worin würde denn nach deiner Theorie der Unterschied zw. private und protected bestehen?

Das habe ich mich dann auch an dieser stelle gefragt *G*

Der Unterschied ist, dass ich in einer abgeleiteten Klasse im Implementations-Teil nicht auf private-Elemente der Eltern-Klasse zugreifen kann (außer ich hab diese vorher veröffentlicht).

Ich meine, das ist eine schöne Sache; da muss ich nicht die ganze TQueue neu kopieren um auf die Liste direkt zugreifen zu können. Andererseits sollte evtl. die Dokumentation ausgebessert werden. Wir dürfen uns also fragen, ob der Fehler jetzt im Kompiler oder in der Dokumentation zu suchen ist

[theo]

Wir dürfen uns also fragen, ob der Fehler jetzt im Kompiler oder in der Dokumentation zu suchen ist

Eindeutig im Compiler. Trägst du den Bug nun im Tracker ein oder muss ich das machen?

[Socke]

Mach du, ich hab schon genug Accounts für alles Mögliche im Internet verteilt und wieder vergessen.

Wenn das aber ein Bug ist, muss ich wohl doch meine eigene TQueue mit Zugriff auf das zugrunde liegende Listenobjekt schreiben

[theo]

Fixed: http://bugs.freepascal.org/view.php?id=14650" onclick="window.open(this.href);return false;

[Targion]

Hihi... Und ich habe mich schon so oft gewundert, warum ich nach Übergabe eines Pointers und derefernzierung auf alle "private" Eigenschaften des Objektes zugreifen konnte...
Das das immer so ist, hätte ich nicht gedacht.

[theo]

Ist ja jetzt repariert.
Wenn sich jemand darauf verlassen hat, könnte er jetzt allerdings ein u.U. grösseres Problem haben

[Socke]

Wie schön, dass ich mit stable-releases arbeite Bis zu v. 2.4 bleibt wohl noch was Zeit

[Socke]

Ähm... mir ist gerade etwas aufgefallen.

Code: Alles auswählen

TOrderedList = class(TObject)
private
  FList: TList;
//...
protected
//...
property List: TList read FList;
//...

das heißt, abgeleitete Klassen haben (indirekten Zugriff auf das Listenobjekt.

Heißt das fürs Ableiten, dass TMyList von der Sprache her zulässig ist, TMySecondList aber nicht?

Code: Alles auswählen

TMyList = class(TQueue)
public
  property List;
end;
TMySecondList = class(TQueue)
public
  property List: TList read FList;
end;

[theo]

Heißt das fürs Ableiten, dass TMyList von der Sprache her zulässig ist, TMySecondList aber nicht?

In TMyList hebst du das property List nur auf ein höheres Sichtbarkeitslevel (protected->public), das ist erlaubt.
TMySecondList geht nicht. private FList sollte für eine abgel. Klasse nicht erreichbar sein, jedenfalls nicht in einer anderen Unit.