Kategorien
SPL – Eigentlich eine wahre Schatztruhe
Sie ist kaum in Verwendung – die Standard PHP Library – aber warum? Die Frage habe ich mir schon öfters gestellt und auch in die Ideenschmiede eingestellt, damit ich mal erfahren kann, wie ihr diese Bibliothek seht. Interesse besteht also, deswegen fasse ich mal kurz meine Meinung zu dieser Sammlung zusammen.
Die Idee, die hinter der SPL steht, ist gleichzeitig einfach und sehr nützlich. Wir haben ein Bibliothek, die von jedem verwendet werden soll und einfache Grundfunktionaliäten zur Verfügung stellt, die jeder gebrauchen kann. Resultat ist auf der einen Seite, dass man das rad nicht neu erfinden muss. Warum müssen sich 100 Entwickler gedanken darüber machen, wie ein Interface für Klassen aussieht, durch die man durchiterieren kann. Ein solches Problem wird ein Mal gelöst und danach nie wieder. Zumindest in der Theorie. Ausserdem wird die Qualität eines Interfaces oft besser, wenn sich mehrere leute gedanken darüber gemacht haben, als nur eine.
Ein weiterer großer Vorteil der SPL ist die resultierende Austauschbarkeit von Komponenten. Wenn alle Entwickler das gleiche Interface verwenden, um zum Beispiel eine Tiefensuche zu implementieren, so kann ich die verwendete Klasse beliebig gegen andere austauschen. Ihr merkt schon, das Konzept des Interfaces ist für mich in dieser Sache sehr relevant.
Vielleicht werdet ihr euch jetzt denken, dass das eigentlich genau wie das Zend Framework oder andere Bibliotheken klingt. Das ist auf jeden Fall richtig. Es sagt ja auch niemand, dass die SPL die einzige Bibliothek sein darf. Sie haben nur einen großen Vorteil, sie sind sehr nahe am PHP Kern, denn die SPL ist Teil von PHP. Ein Iterator Interface, dass mit foreach funktioniert, könnte man nicht umsetzen, ohne in den PHP Kern einzugreifen, was zum das Zend Framework zum Beispiel nicht macht. Die meisten Bibliotheken konzentrieren sich auch eher drauf, komplexere Probleme zu lösen. Ein ZF hat zwar eine Klasse, die sich mit Webseiten Handling beschäftigt, diese wird aber nur benutzt und wird nicht als eigenständiges Feature verkauft. So eine Klasse könnte also in die SPL rutschen, das ZF nutzt sie weiterhin und baut dort seine Features drauf aus. So könnte ich mir das auf jeden Fall vorstellen.
Das Ziel ist also sehr erstrebenswert. Macht euch mal den Spaß und fragt, was ein Java Entwickler ohne Java API tun würde. Wahrscheinlich PHP entwicklen. Standardfunktionalitäten mit der Programmiersprache selbst auszurollen, ist denke ich, eines der besten Dinge, die man machen kann.
Großer Nachteil der SPL ist aber ihr Umfang. Sie wächst lange nicht so schnell, wie andere Bibliotheken, die firmengetrieben entwickelt werden. Vielleicht sollte man mal einen PHP Community Process einführen, bei dem jeder seine Ideen einreichen kann und ein Gremium entscheidet dann über die Übernahme in die SPL. Ich hätte einige Klassen, die ich da einreichen würde und diverse Open Source Bibliotheken hätten sichlich auch einen ganzen Haufen.
*link hinterher werf*
http://de3.php.net/manual/de/book.spl.php
@ghost: Super Punkt 🙂 Hab’s grad mal verlinkt im Text.
😉
Bei der Gelegenheit grad mal das Dokument überflogen. Sind ja echt ein paar coole Dinge dabei, die ich noch gar nicht ausprobiert hab *g*
Ist die SPL nicht in C programmiert? Das würde mich davon abhalten, eigene Komponenten für die SPL zu schreiben, da ich, wie wahrscheinlich viele PHP-Entwickler, keine Lust habe, in eine Low-Level-Sprache zu programmieren. 😉
„Ein ZF hat zwar eine Klasse, die sich mit Webseiten Handling beschäftigt, diese wird aber nur benutzt und wird nicht als eigenständiges Feature verkauft.“
Den Satz verstehe ich, ehrlich gesagt, nicht so recht. Was ist mit Webseiten-Handling gemeint und warum wird das nicht als eigenständiges Feature verkauft, wenn es doch im Zend Framework enthalten ist?
Wenn es das ist, was ich denke, dann frage ich mich, was dieses Webseiten-Handling in der SPL zu suchen haben sollte, denn für solche komplexen Probleme gibt es genügend in PHP geschriebene Varianten, bei denen man die Fehler i.d.R. selbst beheben kann. Für mich stellt die SPL eine sehr gute Erweiterung von PHP um grundlegende Datenstrukturen und Schnittstellen dar, aber komplexere Aufgaben sollten von PEAR oder anderen Bibliotheken gelöst werden.
@Andre: Naja es geht mir drum eine Bibliothek aufzubauen, die sich mit dem Fundament beschäftigt. So wie die Java API. Einfache Probleme sind gelöst und ich kann Standard Klassen verwenden, die gegen Standard Interfaces programmiert sind.
Ein ZF Framework widmet sich meiner Meinung nach in vielen Dingen sehr komplexen Problemen. Wie steuere ich zum Beispiel den Amazon Webservice an. Dass sie aber eine Klasse haben, die das ganze URL Handling (Validierung, Protokollunterstützung, Headerverarbeitung, …) haben, merkt man als Anwender nicht. Und genau diese Zwischenschicht, würde ich gerne in der SPL sehen. Ob es in PHP oder C geschrieben wird ist mir da sehr egal, ich will die Funktionalität.
Also eigentlich hätte ich gerne eine Kopie der Java API 🙂
@Andre Moelle:
Ja, die SPL ist in C programmiert und ich stimmme dir auch zu, dass es viele abschreckt. In C kann man halt doch viel falsch machen, wenn man nicht genügend erfahrung hat und selbst die machen gern mal noch was „falsch“, wage ich zu behaupten 😉
Was ich mir bei der SPL vorstellen kann, sind sinnvolle Ergänzungen wie via OOP E-Mails zu verschicken und ähnliches. Es gäbe durchaus dinge, die man von in PHP geschriebenen Frameworks in die low level SPL auslagern könnte.
@Nils: joa, das wäre kein schlechter weg, wenn man sowas wie ne abgespeckte java api für php hätte. Funktionsmäßig ist ja php schon sehr mächtig, doch gerade was oop betrifft fehlt mir da so einiges
> Funktionsmäßig ist ja php schon sehr mächtig,
> doch gerade was oop betrifft fehlt mir da so einiges
ACK! *ulli-auf-die-schulter-klopf*
Das klingt für mich so, als solle die SPL die Aufgaben von PEAR übernehmen. Lieber sollte man sich auf die Weiterentwicklung von PEAR – oder einem anderen Projekt, das sich demselben Ziel widmet – konzentrieren, damit die gesamten Komponenten die PHP5-Features nutzen. Eine solche native PHP-Entwicklung würde vor allem schneller von der Hand gehen als ein Rumgefriemel in C.
Eine abgespeckte Java-API wäre wahrscheinlich nichts anderes als die bisher meist recht einfachen Funktionsaufrufe als Klasse zu kapseln. Insgesamt ein großer Zeitaufwand, der vieles komplizierter machen würde. Ich habe neulich geschlagene 15 Minuten gebraucht, um in Java die aktuelle Zeit auszulesen, da diese Klassen überabstrahiert wurden und man erstmal die Dokumentation wälzen musste um zu verstehen, was dort überhaupt gemacht wird. Dazu kann ich nur sagen: Nein, danke. Da bleibe ich lieber bei PHP und verwende die date-Funktion…
Prinzipiell halte ich nicht viel davon, wenn wesentliche Komponenten in C geschrieben werden, da dies den meisten PHP-Entwicklern die Möglichkeit raubt, bei der Entwicklung neuer Komponenten zu helfen, da man nicht nur C beherrschen, sondern auch wichtige Details aus dem PHP-Kern kennen muss.
@Andre: Wie gesagt die Sprache ist egal. Gerne eine PHP Bibliothek in PHP geschrieben. Es hat natürlich gro0e Vorteile, wenn sie vom PHP Core unterstützt werden (siehe Iterator).
PEAR hatte mal einen ähnlichen Ansatz, da gebe ich dir recht, aber auch die PEAR Komponenten, die ich kenne sind wieder eine Schicht zu hoch. Es sollen wirklich nur ganz grundlegende Dinge drinnen sein.
Ich gebe dir Recht mit der Aussage, dass so was standardisiert sein sollte, aber ich finde, dass die SPL der falsche Platz dafür ist, worüber sich natürlich streiten ließe. Für wirklich grundlegende Datenstrukturen ist die Nähe zum PHP-Kern sehr wertvoll, aber ich kann mir nicht vorstellen, dass diese für die Schicht zwischen der eben genannten und den PEAR-Komponenten notwendig ist. Mir reicht es jedenfalls zum derzeitigen Zeitpunkt, wenn ich weiß, wo ich solche Komponenten finde und wie ich diese einsetzen kann.
Ich bin ja immer noch dafür das kernteile des ZF als PECL erweiterung geschrieben werden sollten. (funktionierte zb. bei adoDB auch hervorragend)
Aber zum Thema: SPL einmal verwendet und nicht mehr hergegeben. 🙂
Ludwig
PS: @Nils: Schon Pläne für das 1 Jährige ?
@Ludwig: Natürlich! Was genau, wird aber noch nicht verraten.
Also ich könnte ohne die SPL glaub ich nicht mehr Leben, gerade die Iteratoren haben es mir angetan, der Recursive-Directory-Iterator zum beispiel, sowas sagt mir viel mehr zu wie mit glob irgendwelche listen zu erstellen.
@robo47 So geht’s mir auch, nur leider sind die Features doch sehr beschränkt. Noch!
Zu schade das vielleicht 0,5% der PHP Fri…ähh Entwickler die SPL kennen.
@Bartek Die Frickler nicht, aber die Entwickler und das werden immer mehr.
Ich denke das Problem ist einfach, dass oftmals nicht „über den Tellerrand“ geschaut wird, wer gleich in PHP groß geworden ist – ohne eine andere Sprache (gibt es ja leider doch immer häufiger) – kennt viele Konzepte gar nicht.
In PHP wird für Container erstmal alles in Arrays gesteckt, und warum?
In PHP sind Arrays eine eierlegende Wollmilchsau, die Implementierung gleicht dabei mehr einer LinkedHashMap aus Java.
Aus solchen Gründen, werden dann Dinge wie Stacks, LinkedLists oder FixedArrays gar nicht mehr angeschaut, die Performance ist bei einem Script welches nur einen Bruchteil der Sekunde läuft egal, und wenn nicht, dann nimmt man einfach einen weiteren Webserver dazu.
Und die schöne Sache der SPL-Iteratoren wird noch brauchen, bis es allgemein genutzt wird. Ich bin ja froh, dass seit PHP5 Objektorientierung so gut angenommen wird (auch wenn es noch zuviele „Frickel“-Systeme wie WordPress gibt, die auf einer Masse von Funktionen aufbauen), aber PHP hinkt anderen Enterprise-Sprachen (oh Gott, die Buzzwords wieder) nunmal einige Jahre hinterher, wenn auf breiter Fläche mal überall (!!!) objektorientiert mit Design Patterns gefahren wird, erst dann wird die SPL die Beachtung finden, die ihr zusteht.
Was viele Leute eher an der SPL abschreckt, die den Namen schon mal gehört haben, ist die absolut schlechte Dokumentation dazu.
Wären da auch ein paar Snippets, UseCases und ne Beschreibung, „Wozu das ganze?“ dabei, würde die SPL durchaus mehr anklang bei den Leuten finden.
Ich muss mich da meinem Vorgänger Tobias anschließen… Wer nicht Kontakt mit anderen Programmiersprachen hatte und dortige Container-Klassen kennen lernt, denkt an sowas in PHP garnicht, nachdem einem mit den Arrays schon ein überladener Alleskönner vor die Füße geworfen wird.
Also mir hat für die SPL das hier:
http://www.php.net/~helly/php/ext/spl/
besser gefallen als der Kram im Handbuch, vor allem war das auch immer aktueller, sind allerdings auch Sachen drin die PHP 5.3 only sind und so.
@ Nils: Naja, so egal ist die Sprache nicht, in der solche grundlegenden Sachen implementiert werden. Ich behaupte mal man bekommt sowas in C durchaus performanter hin. Andererseits stimmt es natürlich, dass viele PHP-Entwickler damit von der Mitentwicklung ausgeschlossen werden. Aber mal ehrlich: Wieso will ich an solch grundlegenden Sachen mitentwickeln? Ich hatte auch noch nie das Bedürfnis strlen() mitzuentwickeln. Gibts schon, läuft schnell, was will ich mehr?
(OK, ich hatte schonmal das dringende Bedürfnis getdate() mitzuentwickeln, weil es in einer Schleife ähnlicher Timestamps einfach nur ehlend lahm ist, aber das ist was anderes ^^)
Aber danke fürs Vorstellen, kannte SPL noch nicht und werds mir jetzt mal anschauen!
Nachtrag: Scheiße, hätte mir das mal jemand früher gezeigt! Warum steht sowas nirgends???? Da müsste doch bei opendir() im Manual stehen: „Leute, wenn ihr durch ein Verzeichnis iterieren wollt, dann schaut mal in der SPL nach.“
@Christopher: Es hat ja auch niemand gesagt, dass du strlen nachprogrammieren sollst. Es existiert ja schon. Aber so etwas wie eine Linked List, hastables, sortable interfaces, … was es nicht alles nützliches bei java zum Beispiel gibt.
Was ich aber merke, ist dass es uns allen schwer fällt, andere nützliche Klassen zu definieren, außer Collections, sind wir schon so von der SPL gehirnwäsched worden?
Man könnte zum Beispiel eine Matheklasse basteln und dort rein schmeißen oder einen RSS Streamreader … Ich will ja eigentlich nur, dass so etwas standardisiert ist, damit alle das gleiche nutzen und das Rad nicht doppelt erfunden wird. Es gibt nämlich so viele Probleme, die schon gelöst sind!
hmm… aber ne Mathe-Klasse für PHP wär auch nur ein wrapper für die schon existenten Funktionen (http://de.php.net/math).
Und ein RSS reader gehört für mich nicht zum Funktionsumfang einer Programmiersprache, und die SPL gehört laut Manual ja fest zu PHP.
Joa, ums mit unter auf den Punkt zu bringen:
Man müsste x-verschiedene Frameworks im Detail kennen und benutzen um die Core-Features, die ja schon hier und da existieren, nutzen zu können. Wenn es jetzt DIE Klassenbibliothek gäbe, die alle nutzen, täte man sich in jeglichen Projekten leichter, da auch die Basics gleich sind.
Pear kommt dem meiner Meinung nicht ganz nach, obwohl es ursprünglich dafür gedacht war. Wer aus welchen Gründen auch immer noch PHP4 benutzt, der is darüber glücklich, aber es gibt viel zu wenige Klassen die schön auf PHP5 portiert wurden.
gut erklärt wird die SPL auch im PHP Design Pattern Buch von Stephan Schmidt
Etwas Klugscheißerei, sorry muss sein: 😉
Der Iterator is kein Teil von SPL sondern Teil der Engine, (fast?) alles was SPL macht könnte man auch im Userland machen, der PHP Source hat in ext/splinternal/ auch PHP-Implementierungen der Klassen dabei (aus denen dann auch die doku von php.net/~helly generiert wird)
Ah, zwei Außnahmen gibt es: ArrayAccess … das is in SPL und nicht im userland nachbaubar und das Countable interface hngt sich in count/sizeof rein, geht auch nicht im userland 🙂
Sagt mal die zahlreichen Exceptions die SPL bietet, spricht etwas dagegen wenn ich diese selbst einsetze?
Ich will da nämlich bei den Exceptions etwas differenzieren und da bieten sich die SPL Exception an (bsp. InvalidArgumentException)
Kann ich die sorglos in meinem Script nehmen oder sind die Exceptions doch eher was internes?
Das habe ich mich auch gefragt. Ich bin der Meinung, dass man sie schon verwenden sollte, denn ansonsten wären sie wahrscheinlich nicht öffentlich dokumentiert.
Stell dir vor dein Script gelangt in andere Hände und der glückliche muss sich mit deinem Code rumschlagen. Er schaut sich dann die Exceptions an und trifft auf „BadFunctionCallException, RangeException“ usw.
Er atmet auf und freut sich. Warum? Weil er sie kennt, wie viele andere auch. Die SPL mit Ihren Exceptions versuchen einen Standard zu schaffen.
Auserdem sind die Exceptions von SPL in C-Code implementiert, das laden und Parsen von PHP-Code fällt demnach flach.
Ebenso gibt es die Exceptions auch in Java. Mus er mal an dein PHP-Code, warum auch immer, weis er sofort was es mit den Exceptions auf sich hat.
Java ist nur ein Beispiel, die SPL Exceptions werden auch noch in anderen Programmiersprachen benutzt.
Ich denke mal das sind alles gute Gründe warum man die SPL Exceptions nicht ignorieren sollte.
Übrigends finde ich es immer sehr spannend den Links in den Kommentaren zu folgen, man trifft öfter mal auf ganz spannende Seiten. Super 🙂
Gehört nicht hierhin, musste aber mal gesagt sein. Ich glaub ich bin der einzige bei dem man auf ner Tuningseite landet 🙂
@ Bonzei: Bei „Tuningseite“ dachte ich an Website-Tuning ^^ Weit verfehlt *g* Aber was mir aufgefallen ist: Deine Startseite hat 1.8MB und lädt bei mir über 20s. Das ist definitiv zu viel. Bisschen website-tuning tät da nicht schlecht 😉
Größtes Problem: Neben kaum komprimierten Banner und Footer-Grafiken lädst du die kleinen Auto-Fotos unter „Highlights“ in voller Auflösung und lässt sie vom Browser runterrechnen. Hättest du ein PHP-Script, was Thumbs generieren würde, könntest du dir die Hälfte der Ladezeit schonmal sparen.
(Is nur gut gemeint. Vielleicht macht Nils ja mal einen Blogeintrag zum Thema Thumb-Generierung mit PHP ^^)
@nils kennst du das?
http://mtadata.s3.amazonaws.com/webcasts/20090623-spl.wmv