Ich bin ein großer Fan objektorientierter Programmierung und wenn es nach mir ginge, würde ich auch nur Objekte verwenden.
Aber nach mir geht es nicht, das Leben ist kein Ponyhof und ich habe mich so entschieden mein Geld mit PHP- und nicht mit Java-Programmierung zu verdienen. Genug gejammert, worum geht es?
In den letzten Tagen, Urlaub sei Dank, hatte ich etwas mehr Zeit mich durch die Blogwelt zu klicken und habe dabei einen älteren Artikel von Benjamin entdeckt, in dem er seine PHP-Stringklasse vorstellt. Etwas schmunzeln musste ich bei der Lizenz für die wenigen Zeilen Code, aber Ordnung muss sein. 
Die Idee gefällt mir sehr gut keine primitiven Datentypen, sondern echte Objekte zu verwenden.
Inspiriert von der Idee, habe ich ein paar Minuten gebastelt und habe nun meine Custom_String-Klasse. Sie ist einfach umgesetzt, handlich und hat alles was ich brauche.
An der Stelle fiel mir dann auch gleich wieder ein, warum ich das bisher nicht umgesetzt habe.
Wer sich etwas mit Java auskennt, der weiß, dass sämtliche Objekte in gewisser Weise nach bestimmten Mustern funktionieren. Will ich meine Objekte sortieren können, dann implementiere ich einfach das Interface Comparable und gut ist.
An dem Beispiel mit den Strings sollte das Problem klar werden. Benjamin hat eine Klasse für Strings geschrieben, wie er sie gerne hätte, ich habe das getan und viele andere vielleicht auch.
Jede für sich mag gut sein, aber auch etwas anders funktionieren und eine andere Schnittstelle bieten.
In großen Systemen kommen nun die Arbeiten vieler Entwickler zusammen, teilweise sogar aus verschiedenen Teams oder auch Firmen.
Um nun einheitlich mit allen Objekten arbeiten zu können, brauchen wir zwangsläufig Adapter-Klassen und haben damit weitere potentielle Schwachstellen im System. Wir müssten jedes Objekt an den Schnittstellen richtig verpacken und bauschen dadurch den Code auf und wir haben die Adapter-Klassen, die wir ebenfalls mit jeder Änderung der Originalklassen anpassen müssen.
Ich denke, solange PHP nicht im Kern ähnlich wie Java die entsprechenden Schnittstellen vorgibt, macht man sich das Entwicklerleben damit nicht wirklich leichter. Wie denkt ihr darüber?
05.01.2011 um 08:39 Uhr
Dazu braucht es gar keine anderen Entwickler: Die gesamte PHP-Klassenbibliothek benutzt die PHP-eigenen Strings. Das Gleiche gilt natürlich für Booleans, Numbers, usw. ebenfalls. Wenn man also nicht gerade halb PHP wrapped (wrappt?), kommt es immer wieder zu Reibungen, wo man dann die primitiv typisierten „Dinge“ (Objekte sind es ja gerade nicht) umwandeln muss.
05.01.2011 um 08:45 Uhr
Mach doch Ruby
Ich fände es gut, wenn es eine Objektalternative zu den Primitiven gäbe. Neben der Tatsache, dass man – insbesondere bei Strings – viele Methoden direkt am Objekt findet, kann man das type Hinting mehr nutzen (naja vielleicht gibt es das auch mal für Primitive) und würde IDEs unterstützen, da die Auflösung leichter fiele.
Auf der anderen Seite würde man, vor allem bei Zahlen, auch ein Autoboxing benötigen, damit bspw. eine einfache Addition nicht übermäßig komplex würde.
Übrigens würde ich versuchen eine String-Klasse so zu gestalten, dass diese projektweit nutzbar ist. Aber wenn ich da an die Serialisierbarkeit denke …
05.01.2011 um 09:19 Uhr
Sehe ich genauso, allerdings muss ich zugeben dass ich selbst auch schon der Versuchung erlegen bin, eine String-Klasse nach Java-Vorbild zu basteln, mittlerweile verzichte ich wieder darauf, genauso wie auf so fancy hacks wie primitive type hinting¹ und autoboxing², ich freue mich zwar immer wenn ich sehe, was alles möglich ist aber leider geht das immer zu Lasten der Kompatibilität…
¹) http://www.phpclasses.org/package/4195-PHP-Implement-type-hinting-support-for-base-PHP-types.html
²) http://www.phpclasses.org/package/6570-PHP-Wrap-string-and-integer-values-in-objects.html
05.01.2011 um 10:23 Uhr
Ihr habt da etwas missverstanden. Was ihr wollt: OOP-Style auf primitive Datentypen (String, Array, Boolean, Integer, …) zugreifen. Das will man aus zwei Gründen:
1. Endlich mit der Parameterreihenfolge bei String- und Array Funktionen aufräumen. »Wo war $needle? wo war $haystack?«. Simplifiziert die API, macht das Arbeiten angenehmer.
2. $string->slice(0,10)->toUpperCase() ist angenehmer zu lesen als strtoupper(substr($string,0,10))
Was ihr aber nicht wollt, ist das diese Prmitiven auch im Speicher als Objekte vorliegen. Das würde dem RAM vermutlich gar nicht mal so gut bekommen. Davon abgesehen arbeiten sämtliche PHP-core Funktionen direkt mit den primitiven. Man müsste zu viel code anfassen.
Momentan wirft $notAnObject->foo eine Notice, $notanObject->bar() einen Fatal Error. Man hat also zwei wunderbare Angriffspunkte, um bei Bedarf einen “auto cast” oder “implicit cast” zu machen. Man erhielte sich so übrigens auch die volle backward compatibility.
Grüße,
Rod
05.01.2011 um 10:44 Uhr
In der SPL gibt es eine experimentelle Erweiterung, die PHP um Klassen für primite Typen erweitert, inkl. Enum. Für Arrays gibt es mittlerweile ArrayObject. Ansonsten schließe ich mich Rod an.
- http://de.php.net/manual/en/book.spl-types.php
06.01.2011 um 09:23 Uhr
Solange ich nicht $string = “foobar” schreiben kann, und daraus automatisch ein Objekt wird, macht das ganze auch nicht wirklich Spaß. Das wird doch fast exponentiell mehr Tipparbeit oO