OOP: Sichtbarkeit in Unterklassen - Verständnisfrage

[jack88]

Was in der Zend-Engine intern vorgeht, muss nichts mit Buchweisheiten über OOP zu tun haben.

Stimmt, aber das bedeutet umso mehr, daß man über die Unterschiede gut Bescheid wissen sollte. Schließlich folgt auch die OO-Implementierung in der Zend-Engine bestimmten Regeln und nicht dem Zufallsprinzip.

Schlimmstenfalls ist das ein Fehler in der Dokumentation (wenn es dort nirgendwo erwähnt wurde.). Das muss man akzeptieren oder sich eine andere Spielwiese suchen. Es gibt schließlich genügend Alternativen mit vernünftig(er)en OOP-Implementierungen.

Manchmal geht es eben nicht anders als sich mit einem Fehler zu arrangieren. Aber auch hier gilt, daß man der Sache immer zuerst auf den Grund gehen muss. Man kann aus Fehlern bekanntlich auch lernen [FONT=Wingdings][FONT=Wingdings][/FONT][/FONT][FONT=&quot]
[/FONT]

Ich halte, ehrlich gesagt, nicht sooo viel von Galileo-Books, obwohl ich welche (gedruckt) im Regal stehen habe. Man findet (früher oder später) immer wieder handwerkliche Schwächen, wenn man sich mit ihnen beschäftigt

Und ich halte nichts von Pauschalisierungen. Diese erweisen sich nämlich meistens als falsch.

Konstruktoren (in PHP) gehören aber nicht direkt zur Schnittstelle eines Objektes, sondern zur Klasse. Sie werden (normalerweise) nur über den Operator new aufgerufen

Für Konstruktoren gelten bezüglich der Sichtbarkeit die gleichen Regeln wie für Methoden und Eigenschaften. Wie diese aufgerufen werden ist in diesem Zusammenhang unerheblich.

Und wie dir Quetschi und combie schon erklärt haben, gelten für in PHP eingebaute Klassen eben manchmal andere Regeln als für gewöhnliche, vom Anwender deklarierte, Klassen.

Mag sein, ich weiß es nicht (vielleicht kennt ja jemand ein Beispiel?). Ich kann nur sagen, daß es bei der MySQLi Klasse nicht so ist. Für diese Klasse gelten die gleichen Regeln (zumindest bezogen auf das beschriebene Problem) wie für jede andere „normale“ PHP-Klasse auch.

Diese Schlussfolgerung ist unlogisch, was hat imperative ("prozedurale") Programmierung hiermit zu tun

Ok, das nehme ich zurück

Schon seit Juli 2010 nicht mehr.

Stimmt nicht ganz. Die Änderung betrifft nur die namespaced-classes. In non-namespaced-classes kannst Du nach wie vor beide Kostruktor-Varianten verwenden.
[FONT=&quot]
[/FONT]

Methods with the same name as the last element of a namespaced class name will no longer be treated as constructor. This change doesn't affect non-namespaced classes.
<?php
namespace Foo;
class Bar {
public function Bar() {
// treated as constructor in PHP 5.3.0-5.3.2
// treated as regular method in PHP 5.3.3
}
}
?>

Wenn du jetzt eine praktisch vorkommende Situation beschreiben kannst,...

[FONT=&quot;]Ja, gerne – ein mögliches Zukunftsszenario -, wenn die veraltete Konstruktor-Variante irgendwann auch in den non-namespaced-classes abgeschafft wird. Jede Unterklasse die die Sichtbarkeit des Kostruktors der Basisklasse „auf eine unerklärliche Art und gegen die OOP-Regeln“ einschränkt und heute noch prima funktioniert, wird dann sofort Ihre Arbeit verweigern. :-)[/FONT]

[h3ll]

Stimmt nicht ganz. Die Änderung betrifft nur die namespaced-classes. In non-namespaced-classes kannst Du nach wie vor beide Kostruktor-Varianten verwenden.

Dann verwende eben Namespaces. Dazu sind sie ja da. Die Namespace-lose Programmierung ist als Kompatibilität zu Vorgängerversion zu sehen.

Wenn du "veraltet" programmierst, dann hast du eben noch die veralteten Konstruktoren dabei.

[jack88]

@h3ll

na klar - prima Idee, nur wie soll ich einer "veralteten" BuiltIn-Klasse wie MySQLi einen neuen Namensraum zuweisen?

[h3ll]

na klar - prima Idee, nur wie soll ich einer "veralteten" BuiltIn-Klasse wie MySQLi einen neuen Namensraum zuweisen?

Sie hat schon einen Namensraum. Den globalen Namensraum. Du musst da gar nix machen.

[jack88]

@h3ll

Sie hat schon einen Namensraum.

du sagst es ;-) Und genau das ist auch das Problem, denn im globalen Namensraum dürfen beide Konstruktor-Arten verwendet werden.

Man kann es drehen und wenden wie man will. Es ist eine "kleine" Schwäche in der Konstruktor-Implementierung - vielleicht auch gewollt bzw. bewußt aus Kompatibilitätsgründen in Kauf genommen .

[fireweasel]

... Schließlich folgt auch die OO-Implementierung in der Zend-Engine bestimmten Regeln und nicht dem Zufallsprinzip.

Nicht dem Zufallsprinzip, aber die Änderungen oder Ver(schlimm)besserungern erscheinen (zumindest mir) doch oft sehr willkürlich ("random").

php.internals: Re: RfC: rethink OO inheritance strictness

Und ich halte nichts von Pauschalisierungen. Diese erweisen sich nämlich meistens als falsch.

Ich finde in meiner Aussage keine Pauschalisierung. Sie beruht auf Erfahrungen, die ich mit Sachbüchern dieses Verlages gemacht habe.

Für Konstruktoren gelten bezüglich der Sichtbarkeit die gleichen Regeln wie für Methoden und Eigenschaften. Wie diese aufgerufen werden ist in diesem Zusammenhang unerheblich.

class method - Should constructors comply with the Liskov Substitution Principle? - Stack Overflow

Mag sein, ich weiß es nicht (vielleicht kennt ja jemand ein Beispiel?).

Wofür? Für die Andersartigkeit von internen und Userland-Klassen oder -Objekten?

Ja, gerne – ein mögliches Zukunftsszenario -, wenn die veraltete Konstruktor-Variante irgendwann auch in den non-namespaced-classes abgeschafft wird. Jede Unterklasse die die Sichtbarkeit des Konstruktors der Basisklasse „auf eine unerklärliche Art und gegen die OOP-Regeln“ einschränkt und heute noch prima funktioniert, wird dann sofort Ihre Arbeit verweigern.

Nein, wieso sollte sie? Bei Aufruf des (PHP-5-)Konstruktors muss die Klasse bekannt sein. Du kannst sie nicht durch eine abgeleitete Klasse ersetzen, ganz im Gegensatz zu einer Objekt-Referenz. Hier kannst du jederzeit eines der Basisklasse durch eines einer abgeleiteten Klasse ersetzen.

Aber möglicherweise reden wir aneinander vorbei. Ich betrachte die PHP-4-Konstruktoren als Altlast und verwende sie nicht. Welche Konstrukte[sic!] man prinzipiell auch damit basteln könnte, in vernünftigem Quellcode haben sie nichts zu suchen.

[h3ll]

Niemand zwingt dich im globalen Namensraum Klassen zu erstellen.