More Obscure PHP

   One of the more prominent features of PHP is its vast collection of built-in functions, even before
you start adding in optional extensions. This is arguably a failing because it makes the job of
deciding which function to use in a given situation that much more difficult. Many of the functions
are so similar in behavior that it’s sometimes hard to see why they exist as distinct functions.
split() or preg_split()? str_replace() or strtr()? ksort(), asort(), rsort(),
natsort(), usort() or uksort()? strftime() or date()? This book doesn’t go into the lack
of conventions regarding the naming of functions or the order of arguments, or the way in which
several functions are merely aliases of others.

   One cause of PHP’s overlapping set of functions is its early existence as a mere wrapper over
Perl’s and later C’s own libraries. Users familiar with those languages’ function libraries would
find their PHP equivalents going by the same names with the same calling conventions, overlaid
with PHP’s memory management and type handling. Extensions exacerbated this—with different
DBMSs exposing different APIs, PHP introduced different sets of functions for each DBMS it supported.
When two extensions boasted functions for two similar things, PHP provided both.
As PHP became implemented more expansively on a wider variety of platforms and built into a
wider variety of environments, platform-independent implementations of functions began to be
introduced. Hence the existence of both rand() (which uses whatever pseudorandom number
generator was supplied by the C compiler PHP was built on) and mt_rand() (which has identical
behavior across all platforms). At the same time, PHP developers have been committed to backward-
compatibility; even as new mechanisms are introduced, they do their best to retain the old
ones in case there are people relying on them.

   So PHP’s function list burgeoned, bulging out like a loaf of bread rising in a tin that’s too small for
it. At last count, the PHP manual had 3,630 function entries, distributed among 129 chapters, of
which 855 are listed in the 30 chapters that the manual describes as “core” or are bundled and
require an explicit configuration switch to disable. Those figures are already out of date.
The practical upshot of this is that many PHP programmers are like English speakers—they use
only a small subset of the language. There are parts of the language they may just not have any use for. But hidden among PHP’s esoterica are some functions that don’t get the attention they deserve. These
are functions that have been present in PHP since version 4.3.2 at the latest—many have been around
since the early days of PHP 4. Despite this, they are often overlooked, even when they are ideal for the
task at hand. Some of them seem to be used only in tutorials about them. They are by no means the only
obscure features of the language. Rather, they represent some of the more powerful core functionality of
the PHP environment and are areas which are the site of active development in recent versions.

This chapter seeks to redress some of this injustice.

From: Profressional LAMP

PHP5 OOP

    When you begin a new project, one of the first things you have to consider is the structure of your
code. Whether you’re coding something as simple as an online contact form, or as complex as a
full-featured content management system, how you organize your code is going to influence the
performance and maintainability of the end product.

    When you use a language like PHP, there are two main routes you can go: procedural programming
and object-oriented programming—OOP for short. Each strategy has its own benefits and
limitations.

Procedural Programming versus OOP
Procedural programming often emphasizes writing code that is as concise as possible and coding
directly for the end result. In other words, most procedural programming uses targeted groups
of functions that immediately address the problem at hand—usually nothing more, and nothing
less. In most situations, this gets you extremely efficient and high-performance applications. One
of the downsides to this approach is a lack of maintainability. If the project grows large enough,
the developer or developers could end up having to maintain a large number of individual functions,
and in some cases, the logic of different functions can become confusingly similar.
Object-oriented programming (OOP), on the other hand, emphasizes abstract relationships and a
hierarchy of related functionality. Similar functionality can all share a common core, making maintenance
much easier. Code reuse is increased as well, as you can easily adapt the abstracted base
functionality for new tasks. OOP also can aid in large-scale program design, helping encapsulate
and categorize the different sets of functionality required by each part of the system. Such organization
and modularity can come at a price, however. If your object-oriented system is poorly
designed, it can actually be harder to maintain than any of the alternatives. Often, the extreme
modularity and “code-heaviness” of object-oriented designs can suffer from poor performance.

   Once you get past the problems caused by poor object-oriented design, you will find that creating a system
using a custom set of PHP objects, or even a full-blown API, can yield benefits that most every
developer will appreciate. With that, you can now begin to take a look at how PHP5 implements objectoriented
programming.

Basic Class Definitions
The basic unit of code in object-oriented PHP is the class. Simply put, a class is a way to encapsulate
related functionality and data in one entity. This encapsulation can be used to hide internal operations
from external code, and helps simplify the external interaction with the data. A class is a formal description
of a grouping of code, a programmatic recipe if you will. A class by itself, like a recipe, is merely a
cluster of instructions, and not something that can directly be used—you don’t eat the actual recipe, do
you? To use classes, you will create an instance of the class, called an object—similar to using the recipe
to prepare a dish you can actually eat. Classes define the properties and actions of a group of code, and
objects are individual instances of that set of commands.
An easy way to understand classes is to relate class code to physical objects. Many times, classes
would represent these real-world objects. You might have a class named Car that has a property called
occupants, which might keep track of the number of people in the car. It might even contain a method
called brake(), which would perform its similarly-named task. Like many real world items, classes
have a combination of attributes that describe the individual object, called properties in OOP, and a set of
actions that they can perform, which are called methods in the object-oriented world.

From: Profresstional LAMP

What’s New in PHP5?

    So what’s the big deal about PHP5? If you’re experienced with PHP4, you probably know about
object-oriented programming and the way this was handled with PHP4. If you’re unfamiliar with
PHP, but you’re familiar with other programming languages, you’ll probably find PHP5’s implementation
of object-oriented principles familiar. Luckily, things have become a lot easier with the
release of PHP5. However, there are other improvements and changes, such as more configuration
options in php.ini and a host of new array-related and other functions, besides just “better objectoriented
programming” handling. This chapter outlines these changes for you.

Object-Oriented Changes
    The changes that follow relate to the OOP model and associated features and related topics. The
majority of these changes are covered in greater detail in Chapter 2, but are also briefly outlined
here for your quick reference.

Passing Objects
One big impact of OOP changes in PHP5 is the way that variables are passed as parameters to functions.
In PHP4, by default, variables were passed by value instead of by reference, unless denoted
otherwise with the syntax &$varname. In PHP5, the default is to assign a value by reference.

Exceptions
In a nutshell, exceptions are the procedures that happen when something goes wrong. Instead of
your program completely halting when it reaches an unexpected error, you can now exert a little
more control over what the program should do when it reaches said error. You are probably familiar
with the set_error_handler() function available in PHP4. If you aren’t, the purpose of this
function is to define a user function for error handling. However, it had many limitations in its
implementation. For example, it would not work if the error was type E_ERROR, E_PARSE,