What's That Noise?! [Ian Kallen's Weblog]

All | LAMP | Music | Java | Ruby | The Agilist | Musings | Commute | Ball
Main | Next day (May 17, 2004) »

20040516 Sunday May 16, 2004

objects versus ad-hoc data structures in PHP I'm in the midst of changing how a complex data structure is defined. This data structure is returned from a user defined PHP function (i.e. not built-in to PHP or one of its extensions) and the semantics of how the data should be populated needs to change. The quick-n-dirty hacker in me appreciates how easily the data can be assembled and assigned values but my inner object oriented programmer bristles at the kind of mess that has ensued.

There are tons of books from all of the usual suspects (O'Reilly, Wiley, SAMS, etc) about how to program with PHP but leveraging its crude support for OOP and employing best practices around that is seems to be pretty thin in all of the literature I've reviewed. The discussion I've seen on the web about object oriented PHP have also seemed weak; the commenter's who snivel about how complex OOP with PHP is underscore how toyish the use of PHP seems to be in many projects.

Before sending mail or posting comments insulting me for not appreciating PHP's simplicity, make sure you tell your Perl programming friends as well. I've been an adherent to OO in Perl for a number of years (though admittedly fell out of practice while my work was J2EE based) -- my gripes about prevelant practices amongst Perl programmers would be similar the above critique of PHP. In Perl, if you have a big blob of data and you want to find out what the heck is in it, you pretty much have to rely on Data::Dumper or, in PHP, print_r and then pick-apart the output to suss the structure that was created. Perl's man pages have several entries about lists of lists and and a data structure cookbook and so forth but the value of defining objects that provide a structural representation of the data (and of course, semantics) are too often overlooked in real software projects. If the changes I'm currently working on implementing had been using an instance of a class, I'd be looking at the object interface and making changes to the method calls. Instead, I'm looking at a big tangle of opaque data structures.

I could go on and on about how must PHP literature closely binds business logic and UI logic and the hideous morass that that creates, but I guess I already griped about that sufficiently in my high level rant about J2EE versus PHP. <sigh>

The code base I'm currently working on has a long way to go before the business data is captured in clear class definitions and there's a greater level of transparency into the relationships of the things within the application, but we'll get there. ( May 16 2004, 09:46:10 AM PDT ) Permalink