How I Learned to Stop Worrying and Love the String Object

PHP was the first programming language that I understood fluently. Sure, I had dabbled in BASIC, Java, ActionScript (3.0 is pretty awesome), and a few others, but PHP was the first language that I felt truly comfortable with. It wasn't until I moved onto JavaScript that I started to understand a feature that some of my earlier languages had: object based coding. Everything is an object. When you have any variable and you want to manipulate it you can (usually) just call a method from within the variable. Compared to how flat PHP is, this concept really shook my faith in my most familiar language.

  1. 

  2. // let's make the string 'Monday' lowercase

  3. 

  4. // in PHP

  5. $string = 'Monday';

  6. $string = strtolower($string);

  7. echo $string; // echoes 'monday';

  8. 

  9. // in JavaScript

  10. var string = 'Monday';

  11. string.toLowerCase();

  12. alert(string); // alerts 'monday';

Looking at this in terms of code readability and cleanliness, JavaScript variables seem so elegant compared to PHP. All of the functionality that you'd want a string to have is nested within the variable itself. I've always been big into writing code for humans to read, not computers, and this syntax and usage seemed to make a lot of sense. Once I started to learn more about object-orientated PHP I decided to try build an entire library of classes that could wrap variable types.

This was when I built the string object. It wasn't complex. It didn't have to be complex. There were a few basic methods: the obvious __toString(), casing changes, length calculations, etc. After this one I moved onto more fun objects, including arrays and different number objects. The most useful one by far was the date object where I could call a simple $date->shortFormat() or $date->friendlyFormat() instead of worrying about the crazy date() format specifications or timestamp math.

To test out the system I kept all of these objects locked up on the ORM level. When I looped through a MySQLi result I would set each value to it's appropriate data type. This made for an elegant setup… values were set in data objects, rows of values within a model, and rows of models (or a full result) would be a collection. Outside of this clean setup there were a few issues, though. If I wanted to do any logic or checking I'd have to cast it down to flat variables. There is only a __toString() magic method and no __toNumber(), so I had to deal with numbers as strings or call a getValue() method. I also noticed small performance losses thanks to the extra code and files. After keeping this test system live for the better part of a year I took it down and simplified my entire ORM.

After I took out the data objects I thought a lot about what difference they had made. My code had some long-winded workarounds and had scary memory usage. I've looked a bit into the SPL library for PHP, which may have helped with the performance, but I was mostly interested in the readability and usability. It was nice to have some things like $date->getXMLDisplayFormat() instead of having to remember how RFC 822 worked, but the extra measures I had to take in other spots in the code created horrible muddy messes. If there was more functionality built into PHP to handle objects things might have turned out differently.

However, now a year later, I do miss the objects. They may have taken a bit of extra work and specialization to use, but any new technique does. Their usefulness in a large team environment would be invaluable to maintain consistency across different interfaces. They may have had their shortcomings, but for a programmer who enjoys object-orientated programming, a little bit of experimentation and extra code is worth making PHP a little less archaic.