PHP is a serious contender for "best bet" for developing robust web applications on the IBM i, but how much do we know about it? Or, more appropriately, how much do you know about it?
This is going to be the start of a series, a series on PHP. And that certainly seems appropriate as PHP is one of a number of ways to do web applications from the i. And from my point of view, it's one of the best ways. But unfortunately, it still remains pretty much one of the best-kept secrets in the i world for many of us.
So what are we going to do here? Well, maybe the best way is to start is to talk about what we are not going to do.
No "Hello World"
We are not going to do "Hello World." It seems like everybody starts with that as a way to show how really, really simple PHP is. Unfortunately, as you might expect from a full-function language that's over 20 years old, doing really useful things in PHP is not always as trivial as that simple display trick.
Oops, shouldn't have said that. Probably 80% of the people reading this article just stopped. No problem. I would rather be truthful than read. Actually, that's not true, but let's keep going anyway.
The goal here will be to introduce you to object-oriented (OO) programming slowly so that you're not scared off, but not so slowly that you won't learn anything important early on. Rather than approaching PHP by looking at the syntax rules, we'll concentrate on developing practical OO modules, and learn the syntax through that.
And in line with that, I'll talk about some of the other pieces of software that are generally used with PHP, things like Composer and others that are not part of PHP per se but are generally part of the process in doing OO (or any serious PHP app for that matter).
No Procedural PHP
And we're not going to bother with the procedural side of PHP. PHP can be written procedurally, like RPG, but a fully functional OO side was added a number of releases ago, and it's what you really should be using for effective web development.
I know OO scares some people, but most of that is because when we say OO we think of Java. And that reputation is well-deserved. With Java, there's a fair amount that you have to learn, and a fair amount of retraining for your brain before you get good at it. It's certainly far from impossible, but it does take time. But PHP is more forgiving than that. You seriously can produce useable code pretty quickly using OO in PHP, and if you're going to learn the language why bother with procedural when you can use the real thing?
Maybe the biggest shift you'll have to make for OO PHP is how you look at developing applications.
In the RPG world, we're used to thinking big. We start by thinking about the full program that we'll need to build in order to create our application. And from there, we gradually work our way down into the detail, getting more and more specific as we develop.
But in the OO world, whether it's PHP or something else, you tend to think small. Applications tend to be somewhat assembled rather than built. That is, in the OO world you're always looking for previously written modules that you can use to help build your app. You probably won't assemble all of it that way, but reusable code is an important part of the process.
Single Logical Idea
But it's more than just looking for code modules you might use. Even if you write everything yourself, you still want to think small. Modular.
Of course, you must start by looking at the large picture, what you're really trying to accomplish with this app. But the next step is to break that big picture down into a series of logical ideas, and those logical ideas are the things you're going to concentrate on in OO. Rather than each of those being a set of code lines, whether contiguous or not, each logical idea will become a code object, an element of a class.
We'll have to be careful how we define that "single logical idea." There's no point in making it too small. An eval statement (taking an RPG example) is not a single logical idea. It should be defined as something that you never need to subdivide. And, at the same time, it should be large enough that it accomplishes something useful—connecting to a table, for example.
Finally, I'll try to interweave best practices information into things as I go. One of the things that was hardest for me to learn when I first started to get into PHP was how very different code from different developers looked. There are a lot of ways to accomplish something in PHP, and sometimes I just wanted to know one way and see everyone using that. That might be too much to ask, but I'll try to show you the ways that some of the more prominent PHP people like to do things.
So I hope you'll follow along in future articles. I'll take it slow and easy so that there's no reason why everyone can't jump on board and learn to do OO PHP.
First stop? Setting up your PC for PHP development. Next time.