A few days ago I ran across 2012: A Year in PHP which is a blog post highlighting what changed in PHP during 2012 and what upcoming changes we can expect in 2013. The post sparked a lively discussion on Hacker News which unfortunately basically devolved into a mix of anti-PHP rants and some “meta” commentary. Anyway, as someone that uses PHP daily I started thinking about what irks me about PHP and what would fix it. Thinking through the issues, it feels like fixing PHP’s type system by making primitives real objects would significantly improve the readability, consistency, and attractiveness of the language.
If strings were real objects…
This one is subjective but I think one of the reasons that PHP code looks so ugly is because the procedural array_* and str* functions look jarring mixed in with object oriented code.
Check out this snippet from the Doctrine ORM framework. Even though the code is “object oriented” and nicely spaced, the array_* and str* functions are a serious eye sore. In addition to looking “off”, the procedural functions have inconsistent argument ordering which leads to “needle or haystack?” bugs.
So what would I switch to? How about a fluent interface replacement for the array and string functions that operate as if they were real objects.
If arrays were real objects…
PHP arrays are in a funny place in terms of how they interact with the standard library and the syntax of PHP. Arrays in PHP are a primitive type and they are arguably the de-facto data structure for most PHP applications. Like strings though, arrays aren’t objects so programmers are stuck using the procedural array_* functions to manipulate arrays. Similar to above, if they were actually objects we could do away with the procedural functions and manipulate arrays with object oriented style functions.
Another array related issue is “foreach hell”, a situation where the easiest way to accomplish a few array related tasks is to run a “for each” over the list which then leaves the code with a tangled mess of collection variables and for each loops of varying lengths. PHP has array_* functions to mitigate this but it wasn’t until the proper introduction of closures and anonymous functions that they became practical to use. Unfortunately, since arrays aren’t objects you can’t really chain any of the functions and the code ends up looking as bad if not worse. If arrays were actually objects, PHP code could easily adopt functional techniques like Javascript’s UnderscoreJS which are usually cleaner and easier to follow.
Compounding the “foreach” issues is the existence of the Iterator interface which allows PHP classes to specifcy that they can be traversed using a foreach loop. This introduces a frustrating limitation in the sense that you can make an object “look” like an array but since the array_* functions only operate on the primitive array type, you can’t leverage any of them on iterable objects. If arrays were actually objects, additional interfaces could be specified to allow some subset of the array_* functions to work on a given class.
In true PHP fashion, arrays as objects actually “sort of” exist within the Standard PHP Library (SPL) Datastructures extension. The SplFixedArray provides a fixed length, integer only array data structure that is actually a PHP object. The problem is you can’t easily just “switch” between using an array versus one of the SPL data structures since they aren’t subsets or supersets of regular primitive arrays, they are PHP classes making them difficult to convert between.
If objects were real objects…
Unlike Java or Javascript, PHP objects don’t all “share” or extend from a common ancestor. In Java, every object extends the Object class and in Javascript every object is connected in the Prototpe chain to the Object prototype. What this shared inheritance fosters is that generic programming is significantly easier because introspection and reflection is more straightforward. Comparatively, check out PHP’s Reflection class to see how much of a disaster introspection and reflection in PHP.
Could it happen?
Unfortunately, I don’t know anything about how primitives PHP types work internally so I can’t speak to how difficult it would be to implement these changes. From a compatibility standpoint, it would naively seem like these changes could be made without seriously breaking backwards compatibility while slowly phasing out the old primitive types. On the whole, as long as we don’t end up with Java’s type boxing issues I think we’ll be in a much better place with PHP as a language.