PHP Looking at Python

Have a look at any message board that is silly enough to actually mention PHP or Python in the title and you have all you need for a virtual battle for the “P” in LAMP. Not to be forgotten is Perl, but that one will have to wait for later. Today’s post will attempt to look at Python from the eyes of a PHP programmer. I will not promise an unbiased viewpoint, but I can tell you right up front that both languages fill a niche for getting certain jobs done quite nicely. Both languages also have some really odd ball things to them… usually for very good reasons depending on how you feel about those reasons.

Although it sometimes feels like there’s a new programming language coming out from somebody every couple of weeks, I believe it is now fair to say that both PHP and Python are very well established platforms for development. Both enjoy considerable corporate support, as well as very active user communities. They also jump across the operating system divide reasonably well.

PHP – Database Creating Objects

Various content frameworks, such as Django or Rails, allow a developer to define the data for the objects they use within the code. From there they then handle creating the database structure on the fly. This frees the developer from having to deal with database structure or most SQL. For myself, I have a lot of trouble thinking in those terms. My thought process involves putting the data structure together on the database, then wrapping my code around that.

Building on my previous article about abstracting your database inserts and my little introduction to Object Oriented design, I would now like to put these two together for you. While I’m at it, let’s see what we can do about pushing many of your data requests to your database into the background by having the table structure define your objects.

Fair warning, not much of what I’m about to get into makes sense without referencing my other two articles. If you’re already comfortable with Object Oriented development you can certainly skip that article (though your comments would be appreciated there).

PHP Namespaces

One of the major issues that Object Oriented design addresses is the problem of having tons of functions and variables all in the same global name space. By modularizing the code you don’t run into the problem of having obnoxiously long function and variable names. More modularized code means it’s far easier to reuse later on different projects without conflict.

While that might seem like the end of the story, it isn’t be any means. As a project grows and starts into using elements of other projects you suddenly find yourself with a whole new naming problem. Now those classes are starting into getting those obnoxiously long names. Other OOP languages that are more established in this realm, like Java and Python, have implemented solutions to these problems long ago. It seems that PHP is finally starting to address this.

Eval Quote

The online PHP manual is perhaps one of the finest of it’s kind anywhere on the web for a programming language. The core information is pretty good, but the user comments that have accumulated over the years really fills in the gaps. Every once in a while a zinger gets tossed in there, and this one got a chuckle out of me.

“If eval() is the answer, you’re almost certainly asking the wrong question.”

Not sure who originally said this, but it is surely sage advice. You can see this in context here if you’re so inclined.

A Different Kind Of DB Abstraction

This is something wonderfully straight forward in putting together a really nice SELECT statement in SQL. There’s all your data just flowing back out at you in the order you asked for. Slap together your HTML around it with PHP and you’ve got yourself a dynamic web page.

If you’ve been doing this PHP thing for more than a project or two you have certainly noticed the mess that is the database functions. An entire stack of functions for MySQL, Microsoft SQL, ODBC, PostgreSQL, etc. Sure, PHP is rich in interfaces to a wide variety of database platforms, but trying to change which platform your using can be a little nightmare. Were you supposed to run mysql_query() or pg_query()? Like many of you, I put together a little set of abstraction tools that we’re pretty much a set of functions that added a layer between the code that needed the data and the database itself. Now that PDO is on the scene it would seem that these kinds of custom libraries are no longer needed.

There is still a place for creating your own libraries though. Implementing tools that push the SQL into the background and allow you to focus on your logic and presentation. In this article I will share some methods I use to abstract UPDATES and INSERTS.

PHP – From Procedural to Object Oriented

I hated the notion of Object Oriented (OO) programming. I’d been using PHP since early version 3, and I had put together some very usable web sites with it. Every book I read on the topic seemed to be rich with metaphors about dogs, cars, and various other things, but not much on why I would want to abandon my happy procedural methods. Not that these authors didn’t try. The arguments they made just didn’t hit home with me at the time.

I think I may now understand why this was. Most of the efforts I’ve seen to describe object oriented design are coming from the perspective of someone who thinks in an OO way. I’m not saying this was a bad approach, it just really didn’t work for me. Perhaps if I hadn’t been so deeply entrenched in the methodologies I had been using for years I would have been more receptive to this type of presentation.

I don’t have any better arguments here for designing in an OO way, but I believe this article approaches the topic from an angle that might make things a bit clearer for people like me. Programmers who have been putting together working sites in a procedural manner and can’t seem to make the mental hurdle into OO.