Kategorien
Fehlt PHP eine Sichtbarkeit?
Als erstes möchte ich mich heute mal bei allen bedanken für die vielen Genesungswünsche. Hat nichts gebracht! Nase läuft immer noch, aber gefreut hab ich mich trotzdem. Als nächstes muss ich mich entschuldigen, dass ich schon eine Weile nicht mehr dazu gekommen bin E-Mail zu beantworten und das phm|network zu aktualisieren. Ich versuch das ganz bald wieder auf die Reihe zu kriegen. Jetzt aber genug gejammert und auf ans Werk.
In PHP kennen wir drei Sichtbarkeiten: private, protected und public. Irgendwann hatte ich auch mal erklärt, was die eigentlich sollen. Gehen wir aber mal von aus, dass das jeder weiß. In den meisten Fällen reichen diese Sichtbarkeiten (oder wie man das auch immer nennen mag) aus. Also um ehrlich zu sein, in den meisten Projekten, in denen ich involviert war, waren die drei vollkommen ausreichend.
Ich spüre schon, wie einige von euch grübeln. „Was für eine zusätzliche Sichtbarkeit könnte es denn überhaupt noch geben?„. Da PHP mit der Version 5.3 Namespaces eingeführt hat, sollte man dort noch eine neue Sichtbarkeit sehen. Wie wäre es also, wenn man Klassen oder Methoden nur zugänglich machen kann, wenn die aufrufende Instanz sich im selben (oder Kind-) Namespace befindet.
Warum mir gerade jetzt diese Sichtbarkeit fehlt? Naja im Moment arbeite ich an zwei Projekten die Plattformen für viele andere Dinge werden sollen. Jede Schnittstelle, die man nach draußen freigibt muss man bis an sein Lebensende weiterpflegen. Meistens ist das Lebensende zwar „nur“ das nächste Major-Release, das kann aber trotzdem nerven. Alles was man verheimlichen kann ist gut. So funktioniert Objektorientierung nun mal.
Also was meint ihr? Sollte man mal eine Mail an den PHP-Gott schreiben und ein RFC einreichen? Vielleicht gibt es das ja auch schon und wir müssten nur ein wenig mehr Druck dahinterpacken. Ich meine, es gibt bestimmt auch Leute, die das anders sehen. Irgendein Franzose hat ja schließlich auch bei Symfony2 private „verboten“. Jetzt aber los … eure Meinung!
Wahrscheinlich meinst du so etwas wie die default-Sichtbarkeit in Java. Gibst du hier an einer Methode keine Sichtbarkeit an, ist diese nur im gleichen Package sichtbar.
Halte ich für nett. Features wie Traits wären mir da für die Entwicklung aber doch wichtiger 🙂
Das wäre, wie Martin schon schrieb, wie die Package-Sichtbarkeit in Java. Da PHP sich in vielen Punkten offensichtlich an Java orientiert, ist es vielleicht auch nur eine Frage der Zeit, bis wir auch das nutzen können (wenn wir es denn wollen).
Ich benutze in meinen Projekten auch kein private Schlüsselwort mehr. Meiner Meinung nach machen private Methoden das ganze Vererbungsprinzip kaputt. Das ist doch ärgerlich wenn man eine Methode überschreiben will die mehrere private Methoden nutzt. Wegen einer vielleicht kleinen Änderung muss man diese als private deklarierten Methoden noch mal neu implementieren.
Ein Nachteil dieses Konzeptes ist es sicherlich, dass wenn sich die Schnittellen der Elternklasse irgendwann ändern, man einen größeren Wartungsaufwand hat.
Keine Ahnung ob ich immer bei der gleichen Meinung bleibe, da ich diese Umstellung eher aus Frust wegen des oben genannten Problems gemacht habe.
Ja, hatte mich da auch an Java orientiert. Hatte ich total vergessen dazuzuschreiben.
Ich habe Objektorientierung damals mit C++ gelernt – und da gab es das „friend“ Keyword, in dem man definieren konnte, dass eine andere Klasse auf private Methoden zugreifen darf. So was vermisse ich bei PHP schon lange.
Package private wäre eine nette Sache. Sieht für mich so aus, als ob die Namespaces nicht zu Ende gedacht wurden. Wenn man wie in Java public explizit angeben müsste, würde das aber auch wieder die Kompatibilität brechen und somit benötigt man entweder den großen Schnitt, oder einen neuen Modifier.
@Christian: Man kann neue Klassen nicht nur durch Vererbung erzeugen. Komposition ist auch ein probates Mittel in der OOP. Im Sinne des seperation of concerns ist die Komposition besser als Ableitung, da die Kapselung nicht aufgebrochen wird.
Bitte nicht die alte „kein private verwenden“ – Diskussion wieder…
Ich finde es eher Sinnvoll, eine Alternative von private und protected zu haben, bei der fremde Objekte des gleichen Typs keinen Zugriff haben.
Momentan funktioniert folgendes ohne Fehler:
bar(); }
}
$a = new foo(); $b = new foo();
$a->barOther($b);
?>
ich fände es aber sinnvoller (und logischer), wenn private Methoden nur von der aktuellen Instanz aufgerufen werden können…
Warum wird hier bei den Kommentaren strip_tags statt htmlspecialchars verwenden? 😉
Nochmal der Code:
class foo {
private function bar() {
echo ‚baz‘;
}
public function barOther(foo $other) {
$other->bar();
}
}
$a = new foo();
$b = new foo();
$a->barOther($b);
Grundsätzlich schadet das nicht. Allerdings hatte ich bisher mehr das Gefühl, PHP orientiert sich stärker an C++ als an Java. Was auch Sinn macht: denn schließlich ist PHP in C++ geschrieben. Nachdem man ursprünglich aus historischen Gründen sich auch an Perl angelehnt hat scheint man davon etwas abgekommen zu sein.
Viel dringender als neue Sichtbarkeiten wären IMHO allerdings skalare Type-Hints, Type-Cast für Klassen, das Überladen von Methoden und ein optionaler Strict-Mode wie in Perl kennt wäre auch nicht verkehrt. Leider ist nichts davon auf absehbare Zeit zu erwarten – außer den skalaren Type-Hints vielleicht.
Gibt’s noch jemanden der auf Magic-Function zum Überschreiben von Operatoren oder für neue Type-Casts wie __toInteger() wetten möchte?
@Thomas Das was dein Code zeigt ist aber ganz normales Verhalten und muss auch so sein. Andernfalls kannst du kein Factory-Pattern benutzen, bei dem eine statische Methode auf private Eigenschaften einer Klasse der gleichen Hierarchie zugreift und diese initialisiert.
Auch so etwas hier wäre sonst nicht möglich:
class Foo {
private $_id;
public function equals(Foo $o) { return $this->_id === $o->_id; }
}
Ich halte es durchaus für sinnvoll, dass dies möglich ist. Aktuell wüsste ich auch keine Anwendung, bei der man dies unbedingt ausschließen sollte.
@Tom „Viel dringender als neue Sichtbarkeiten wären IMHO allerdings skalare Type-Hints, Type-Cast für Klassen, das Überladen von Methoden“
Das wäre echt super, vor allem das Überladen hab ich schon öfters vermisst. Das ständige prüfen durch is_string()/is_array() ist schon suboptimal 😉
Bei deinem private-Beispiel ist die aktuelle Implementation durchaus sinnvoll, daran hab ich garnicht gedacht…
In der PHP-Dokumentation wird als Grund angegeben, „dass die Details über die Implementierung innerhalb solcher Objekte bekannt sind.“
Allerdings gibt es z.B. Situationen, bei denen eine private Methode erst nach einer anderen aufgerufen werden darf, also z.B. execute() erst nach bzw. innerhalb von init() – hier ist es Sinnvoll zu verhindern, dass eine andere Instanz darauf Zugriff hat.
Naja, ist nur so eine überlegung – in der Praxis bin ich mit der aktuellen Implementation gut zurecht gekommen 😉
Hallo, inzwischen sind ja schon über drei Jahre vergangen. Hat jetzt einer schon mal einen Lösung für das Sichtbarkeitsproblem entwickelt?
Ich versuche die Kapselung per Namespaces und Autoloader hinzubekommen, aber dabei kann ich leider nicht sehen von welchem Namespace aufgerufen wird. Oder ob der Klassenaufruf relativ oder absolut war.