PHP, as did most scripting languages, started off without declared types. Scripting languages were always seen is trivial languages to solve trivial problems, and typed variables don’t add much to a 10 line program. JavaScript is probably the most obvious example of this. Who needs types when all you are going to do is modify the DOM when a user clicks a button? But as simple scripting languages evolved and grew into full front and back end solutions, and code base grew exponentially, a funny thing started to happen. Scripting languages started adding declared types!

PHP added class types to parameters in 5.0, then scalar parameter types in PHP 7.1, and even return types in PHP 7.1. In PHP 7.4, typed member properties where introduced and PHP 8.1 added enumerated types. While JavaScript added more defined classes, it took a whole new language, TypeScript, to really endorse types in the JavaScript community. If you study the history of computer languages, you will find this even applies to complied languages. FORTRAN IV had implicit types based on the first letter of the variable name. Variables that started with I, J, K, L, M or N where integers, and everything else was a REAL (or floating point). Newer versions of Fortran (now in mixed case!) include abstract types and even pointers! The transition from C to C++ also introduced much stricter typing.

But Why Bother With Types?

This is a common question from those developers who have never used a strictly typed language. In my experience, if you were introduced to strict types when learning computer languages, you will always be a strict type developer, but if you learned programming with out strict typing, it takes lots of hard learned lessons in failure to finally understand types. The bottom line is types help you create verifiably valid programs with fewer surprises and gives you a higher degree of confidence in your code to work correctly.

But first you need to understand what types are, and then it will become more apparent how types help you and are not a hindrance to better code.

Implicit Types

All computer languages (with the exception of assembly languages) have implicit types. An implicit type is how the language represents the underlying 1’s and 0’s at a specific memory location to you, the programmer. Is the data a 32 bit integer, or a 4 character ANSI string? Should I treat this 64 byte piece of memory as a pointer to another memory location, or treat it as a floating point number? Implicit types are most pronounced when we output them to our users. Should I display this value as a series of characters on the screen, or should I format it as an integer or a number with a decimal point? In PHP, the interpreter decides the data type (int, float, string, bool) based on when the variable is assigned. The following are all different implicit types, and may display in the same way, but are all different.

$a = 1;
echo $a;
$b = true;
echo $b;
$c = '1';
echo $c;
$d = 1.0;
echo $d;

The output of the above is 1111, but each variable has a different underlying representation, they just look the same when output.

Implicit Conversions

Scripting languages hide the implementation differences from the programmer with implicit conversions between types. In PHP, this most obvious when comparing variables. Both PHP and JavaScript have the notion of equality and a strict equality. All the above variables will evaluate to equal if you use the == operator, but will not be equal with the strict type === operator, where not only do the values have to be the same, but the types need to be the same.

Another fall out from implicit type conversions is doing math with strings. ’10’ * 5 will print as 50 since the string ’10’ gets converted to an integer 10 before it is multiplied by 5. While this may be what you want in most cases, it would help if the language would let you know you did this rather than just doing this behind your back!

As your program grows larger, you start to forget about implicit requirements of your older code. Should this variable always be an integer? Maybe it should be a float? You could cause a rounding error by implicitly converting a float to an integer.

The Advantages of Types

1. Correct Math

   Rounding errors are your biggest problem here. If you are dealing with money, rounding makes a financial difference. In the sciences, floating point is common, and you don’t want to accidentally truncate to an integer.

2. Correct Comparisons

   While you can use === for equality comparisons, PHP does not have equivalents for less or greater than. You take your chances that implicit conversion will do what you want in all cases. Better to get the types correct to begin with.

3. Correct Assignments

   A common error is assigning a different type to a variable. This can cause subtle issues later on in the program (see above). It is better to catch these types of errors before bugs manifest themselves much later in the execution path.

4. Correct Arguments to Functions and Methods

   Often you are calling functions or methods that either you did not create, or you wrote a long time ago. Parameter types help you understand the requirements of the method and help insure your usage is more correct.

5. Notes to Future Maintainers

   Types are great for documenting things for future maintainers, or even your future self. Without types, you have no idea of what is required. Is $id an integer, a UUID, or an actual object? Declared types are documentation!

6. Easier Refactoring

   And perhaps the biggest advantage of types is easier refactoring. In PHP, you can use tools like PHPStan to help with type checking your code. When you refactor, PHPStan can help find places you forgot to check from changes caused by the refactoring. Compiled languages with strict type checking will not complete compiling with type errors. And the compiler looks at the entire program, not just one execution path. Developers with compile time strict type checking will tell you this is a huge advantage. I personally have done large refactoring projects with C++ and PHP. In C++, most of my refactoring works the first time once compiled. And the project can move forward quickly with a better design. But in PHP, it takes a lot longer to work through all the issues, even with PHPStan, to get to the better design. And forget about anything but trivial refactoring of JavaScript.

7. Better Confidence Your Code Does What You Think It Should Do

   Besides refactoring, which hopefully you will never have to do that much, stricter typing gives you the confidence that your code is correct. Stupid type errors are caught very early in the development process so they don’t produce unexpected results at 3am in the morning. But this confidence only happens when you consistently apply types everywhere you can, and make them as strict as possible. The more loosely typed something is, the easier it is for subtle bugs to creep into your code base.

Tips for Adding Types to PHP

1. Always Type All Parameters

   This is almost a requirement for any serious PHP developer. Since PHP 7.0 we have been able to type parameters. Not only does this document the code automatically, PHP and PHPStan can catch obvious errors in your logic. And the stricter you can make the types, the more correctly the logic can be validated.

2. Always Type All Return Types

   Functions and methods should always specify return types for the same reason. This helps the calling logic to better understand what is coming back from the method.

3. Use Typed Objects (classes) Where Ever Practical

   Typed objects (from classes) have a huge advantage in type checking, as the class itself can verify it’s own correctness, and passing a fully type object to another class or method further ensures the program executes as you would expect.

4. Initialize Local Variables Before Use

   I always initialized a variable to the correct type before I use it when ever possible. Just setting a variable to the correct type is often enough to catch errors later in the code.

5. Initialize as Much as Possible in the Constructor

   Since properties can now be fully typed, make sure they are all set to the correct types in the constructor or property declaration. This helps insure the object is valid and properly constructed.

PHP still has a way to go with Types

While I love PHP, it still has a ways to go with types. One of the beauties of PHP is implicit typing means your code can be simpler and more flexible, but the downside of that is allowing errors to creep in at runtime or while refactoring. Some languages are completely strictly statically typed and this creates other issues with creating generic reusable code. Modern languages like C++, C# and TypeScript use the concept of “templates” which are classes with substitutable types. But this requires a more complex type system and complex source code. PHP allows for the same thing, but just without any strict type checking, not ideal, but much simpler code.

I think PHP can go further with types and In my next post I will propose a better type syntax that will move PHP forward with types, but not into the realm of strictly typed compiled languages like C++ and C#. But it will help ensure our PHP is more strongly typed and able to catch stupid type errors, which is the entire reason for type checking to begin with.

PREVIOUS: - PHP ORM Wrapup and Benchmarks

A SIDE BAR: - Digital Computers and Digitization

But digital computers do so much more than just text and numbers. In fact, many things in life have been digitized, much to the detriment of many traditional industries. Computers completely changed music, video and almost anything else that can be converted to ones and zeros and then converted back into a close enough approximation of the original.

Living In The Analog World

We live in an analog world. You could say the analog world is actually a wave based world. What we see and hear are actually waves our brain turns into vision and hearing. Light is just a mass of different wave lengths arriving at our eyes. Sound is just the movement of air in waves hitting our eardrums, and we interpret that as sound.

Video, film, and photographs are just representation of light at a specific time. Music and sound are just movement of air over time. Both analog. But computers are digital. They store only ones and zeros, or on and off, or even high and low. How then can we convert our analog waves of light and air into a digital computer and have it come back out again in something we can recognize? After all, digital computers are just that, digital, not analog. They don’t store or compute based on wave forms (unlike analog computers, which we are not discussing here), they use numbers, more specifically, ones and zeros. Do how do we get from one and zero to music we listen to on our computers?

Enter Digitization

The answer, as so often in computers, is to break up the problem into smaller chunks. This is called sampling where the computer takes a very short duration snap shot of the value of the wave form. For photos and video, we have millions of tiny sensors that record the color and intensity of the light at the moment of exposure, and for audio, we record the amplitude of the audio at the time we sample it. We then store that number and repeat the process until we want to stop recording. Video also repeats the process, but for all the millions of sensors in the frame.

The distance between samples is called resolution. The more times we sample audio or the more pixels (sensors) we have in the frame, the higher the resolution of the sampled wave forms.

Why resolution makes a difference

Most people understand resolution in photographs in terms of the number of megapixels advertised for cameras. The higher the number of pixels, the more detailed the photographs become. Most of us will remember the first digital camera or cell phone cameras. Often the resolution was 1 megapixel or less. While these low res images worked, they did not enlarge very well, becoming fuzzy when you tried to zoom in or show on a larger monitor rather then your phone or even the screen on the camera.

But why does a lower sampling rate (say one megapixel vs 20 megapixels) make a difference in how clear the photograph is? Simply because the computer does not know what to put between samples when the samples become further apart. And by enlarging a digital photograph, you are separating the pixels and the computer has to guess what the missing samples might look like. So it employs various techniques that all boil down to educated guess work.

The solution for this is to increase your sampling rate (megapixels) to get a clearer image. The more samples, the less guessing the computer has to do when reproducing the image, and the clearer the image.

While resolution is easy to understand for images, more resolution means clearer images, what does it mean for digital audio? After all, humans can’t really hear any frequency over 20 kHz (20,000 cycles a second). The Nyquist–Shannon sampling theorem says that the CD sampling rate of 44.1k samples a second is sufficient to reproduce all frequencies that humans can hear. But does that mean that a higher sampling rate is wasted on human hearing? Just like images, higher sampling rates in audio mean clearer audio. Since there are more samples, the recreated wave form is closer to the original. Have you ever heard audio in the distance, like a band playing, or a DJ? You almost instantly know if the source is live or recorded. Why? Simply more detail in the waves reaching your ears. Live audio does not go through the digital process, it simple goes through analog amps that might add some noise, but the wave forms are not altered by the electronics. This results in a clearer and more open sound.

Another factor in digital audio is the bit depth or size of each sample. A CD has a 16 bit depth, meaning 16 bits are saved for every sample. The bit depth is directly related to the dynamic range the CD can reproduce. The larger the number of the sample, the louder the wave form is at that point. This is referred to as the dynamic range of the recording. CDs can reproduce about 100 dB of dynamic range, which is well below the limits of human hearing of 140 dB. Higher sampling rates are generally recorded at 24 or 32 bits, meaning they can reproduce over 140 dB of range for a 24 bit recording, and even more for 32 bits.

So both the sampling rate and sample size affect how accurately the original sound can be reproduced.

So what does higher resolution mean in audio?

For photos and video, we know a higher sampling rate means a clearer image or video, but what does that mean for digital audio? Exactly the same thing! Sampling rates above the standard 44.1k of CD’s and 48k of basic video means the sound is clearer. It has more definition and less guessing. I often think of higher sampling rates as lifting the fog of the recording. Things are cleaner, sound seems even more real. You start to notice things like fingers on the strings and fretboard of a string instrument. Higher audio sampling rates are all about recreating the recorded sound more accurately.

But what about Frequency Response?

Frequency response, or what range of frequencies can be reproduced by by a recording system, is an artifact of early high fidelity system marketing. Years ago, playback systems were not great and frequency response was something that could be measured, and therefore marketed. In the digital age, frequency response is a solved issue. But resolution was initially not. People complained (and still do) about CD quality audio. And while mastering techniques have improved, CD’s can simply not reproduce the dynamics of sound humans can hear. High resolution audio can, just like higher resolution photos and video.

Does is make a difference?

And this is the big question. Obviously on your phone, you are not going the hear much difference in sampling rates for audio, photos or videos, because the screens and speakers they get reproduced on simply don’t have number of pixels or fidelity you need for a full quality reproduction. But once you depart from small devices and into larger displays and speakers, you start to notice the lack of resolution in lower sampling rates. Most modern DVD and Blu-ray units can decode 192k/24 bit audio. Amplifiers and speakers are basically analog, so yes, you can hear the difference if you know what you are looking or listening for. Does it matter to you? You will have to make that decision yourself once you try higher res media, but to say it does not matter, is more a reflection on your ability to understand digitization rather than the technology itself.

ORM Design Goals

• Active Record functionality including:

  • CRUD functionality

  • Field names match table column names

  • Fields typed like table columns

  • Fields type checked

  • Field validation with understandable error messages

  • Fields with PHP class types (like Carbon)

  • Virtual Fields

  • Relationships:

    • Parent Record

    • Child Records

    • One To One

    • Many To Many

  • Per class custom logic

• Database Cursors

• Active Table functionality including:

  • SELECT

  • UPDATE

  • DELETE

  • INSERT

  • WHERE and HAVING clauses

  • LIMIT clause

  • ORDER BY clause

  • JOINs

  • UNIONs

• Support for plain text SQL queries

• Atomic migrations

• Auto generation and updating of classes

• Fast and small memory footprint

Mission Accomplished!

If you have been following along with this blog, you will see I covered most of these topics and have implemented all of them in less than 7K lines of OO PHP code in 51 files. You can see the final version on GitHub. But the real test is performance. Does my ORM consume large amounts of memory or perform poorly? For this I decided to perform some benchmarks of my ORM and other commonly used ORM implementations. Let us see how they did.

PHP ORM and SQL Benchmarks

As you might expect, there are very few open source PHP ORM benchmarks available. I did find several, but they were either no longer maintained or not sufficiently configurable. So I decided to write my own. Not only can we benchmark PHP ORMs, but we can also benchmark various SQL servers and implementations depending on what each ORM supports. One thing I did not do is use some sort of virtual machine. The idea is to benchmark against the actual machine that is running the code and compare ORM and SQL server performance on the same physical machine. No need for any abstraction, we want the same base for a comparison. I am sure other hardware platforms may be faster, but by testing everything on the same hardware, we can factor out the hardware and look at just the software performance.

Another issue with synthetic benchmarks is what exactly are you trying to benchmark? A simple CRUD website, or a longer process that updates thousands of records for each run? For a typical website that deals with individual users (most websites), you are looking for two things, one is how fast you can respond to a specific user, and the other is how many users you can serve at one time. The first requires a quick compute light response, the second means you can’t place a high memory load on a server, or you will reduce the number of concurrent users you can support. But if you are doing back end batch processing, you are probably worried about updating massive numbers of records efficiently.

For the type of websites I make, I want a quick response time and a minimal memory footprint, as I want to serve the user quickly, and I want to make sure I can serve a bunch of users at the same time. And each user will only be updating a few records for any one request. I am not processing huge amounts of data in the background, and if I do, it is jobs that might run once a day and are not user facing, so overall efficiency is not a major concern.

I designed my ORM for my needs after seeing some of the performance and design flaws of mainstream ORMs like Eloquent and Doctrine. Let’s see how my ORM stacks up against the PHP heavyweights:

And the Winner is ….

First a bit about the tests. I did one iteration and 1000 iterations. Each iteration inserts a number of (1-X) records, then updates them, then reads them to make sure they are correct, then deletes them. If you just run the test once, it is actually a good simulation of a typical web request where a user hits a page, makes a small update and is done. If you increase the number of iterations to 1000 or more, you start to see how the ORM (and database) responds to bigger backend jobs. My expectations where that my ORM would perform well for single record use cases, as that was my original goal, but I was pleasantly surprised!

Here are the results for overall time for the single record test:

But what about memory usage? Remember I need to keep that minimal to serve lots of users:

And how about larger jobs? Here are the time results from 1000 iterations:

And memory usage for 1000 users:

Takeaways

As you can see, my PHPFUI/ORM outperforms all the other ORMs. Not surprising to me, as I know all these are bloated and slow ORMs from personal experience. Notice the memory requirements of other ORMs are between 10 and 17 times my ORM. This is a major cause of excessive hosting costs, as you need many more machines with lots of memory to handle the the same number of requests.

For the single iteration (the closest test we have to a typical web page request), the best performing ORM was 13 times slower than my ORM on the same database (SQLite memory). Also notice that my ORM performed best for all SQL server based implementations.

Test Things Yourself!

The benchmark suite is open source and available here: https://github.com/phpfui/php-orm-sql-benchmarks PR’s welcome if you see an issue or want to add an ORM.

Here is the config.php file I used to save you some time setting up tests:

return [
    'iterations' => 1, // default is 5000
    'tests' => [
        ['namespace' => 'Cake', 'description' => 'sqlite::memory:', 'dbname' => ':memory:'],
        ['namespace' => 'Cake', 'description' => 'sqlite::file:', 'dbname' => 'cake.sqlite'],
        ['namespace' => 'Cake', 'driver' => 'mysql', 'description' => 'MySQL'],
        ['namespace' => 'Cake', 'driver' => 'mysql', 'description' => 'MariaDB', 'port' => 3307],
        ['namespace' => 'CakeCached', 'description' => 'sqlite::memory:', 'dbname' => ':memory:'],
        ['namespace' => 'CakeCached', 'description' => 'sqlite::file:', 'dbname' => 'cakecached.sqlite'],
        ['namespace' => 'CakeCached', 'driver' => 'mysql', 'description' => 'MySQL'],
        ['namespace' => 'CakeCached', 'driver' => 'mysql', 'description' => 'MariaDB', 'port' => 3307],
        ['namespace' => 'Doctrine', 'description' => 'sqlite::memory:', 'dbname' => ':memory:'],
        ['namespace' => 'Doctrine', 'description' => 'sqlite::file:', 'dbname' => 'doctrine.sqlite'],
        ['namespace' => 'Doctrine', 'driver' => 'mysql', 'description' => 'MySQL'],
        ['namespace' => 'Doctrine', 'driver' => 'mysql', 'description' => 'MariaDB', 'port' => 3307],
        ['namespace' => 'Eloquent', 'description' => 'sqlite::memory:', 'dbname' => ':memory:'],
        ['namespace' => 'Eloquent', 'description' => 'sqlite::file:', 'dbname' => 'eloquent.sqlite'],
        ['namespace' => 'Eloquent', 'driver' => 'mysql', 'description' => 'MySQL'],
        ['namespace' => 'Eloquent', 'driver' => 'mysql', 'description' => 'MariaDB', 'port' => 3307],
        ['namespace' => 'PHPFUI', 'description' => 'sqlite::memory:', 'dbname' => ':memory:'],
        ['namespace' => 'PHPFUI', 'description' => 'sqlite::file:', 'dbname' => 'phpfui.sqlite'],
        ['namespace' => 'PHPFUI', 'driver' => 'mysql', 'description' => 'MySQL'],
        ['namespace' => 'PHPFUI', 'driver' => 'mysql', 'description' => 'MariaDB', 'port' => 3307],
    ],
];

The suite allows you to run all benchmarks consecutively in one session, but I would not recommend that for anything other than testing new configurations as each benchmark can influence the other benchmarks. Instead create a script that calls each benchmark individually by passing the index number of the test as a parameter:

php benchmark.php 0
php benchmark.php 1
php benchmark.php 2

NEXT: - Types Matter!

PREVIOUS: - ORM Record Validation in PHP

So one of my requirements for my ORM was to implement some basic validation for fields with the ability to extend validation for more specific requirements for unique record types. Let’s see how we might be able to do this in an OO manor.

Namespaces to the Rescue Again

Just like our Definition namespace, we can use a namespace to put our validators in and by keeping the same base class name, we can automatically associate the correct validator with the proper record class without any additional configuration. So now we have an \App\Record\Validation namespace with individual validator classes for each record class. The Validation class looks something like this:

namespace App\Record\Validation;
class Member extends \PHPFUI\ORM\Validator
    {
     /** @var array<string, string[]> */
     public static array $validators = [
         'cellPhone' => ['maxlength'],
         'email' => ['required', 'maxlength', 'email', 'unique'],
         'firstName' => ['required', 'maxlength'],
        'lastName' => ['required', 'maxlength'],
         'memberId' => ['integer'],
         ];
     }

As with the Definition class, the static $validators array is indexed by field name and contains an array of validator strings. All validators must pass in order for the field to be valid. The email field is a perfect example. It is required (not blank or null), has a maximum length (the field length), must be an email address and it has to be unique in the database.

Field Comparison Validators

You can compare one field to another on the same \App\Record with the field validators.

• gt_field

• lt_field

• gte_field

• lte_field

• eq_field

• neq_field

Field validators take another field name as a parameter and perform the specified condition test. To compare against a specific value, use minvalue, maxvalue, equal or not_equal.

Passing Parameters to Validation Tests

If you follow a validation rule by a colon (:), you can pass a parameter to the validator. Use commas to pass multiple parameters for a validator.

Putting it all Together in an Example

     public static array $validators = [
         'startDate' => ['lte_field:endDate', 'required'],
        'endDate' => ['gte_field:startDate', 'required'],
        'price' => ['minvalue:0', 'not_equal:0', 'required'],
         ];

This validator requires both a start and end date and the start date must be less or equal to the end date. It also requires a positive price.

Unique Parameters

Without any parameters, the unique validator will make sure no other record has a matching value for the field being validated. The current record is always exempted from the unique test so it can be updated.

If there are parameters, the first parameter must be a field of the current record. If this is the only parameter, or if the next parameter is also a field of the record, then the unique test is only done with the value of this field set to the current record's value.

If the next parameter is not a field of the record, it is used as a value to match for the preceding field for the unique test.

The above repeats until all parameters are exhausted.

Example:

Suppose you have a table with the following fields:

• name

• company

• division

• type

You want the name to be unique per company: unique:company You want the name to be unique per division with in the company: unique:company,division You want the name to be unique for a specific type in the division: unique:type,shoes,division You want the name to be unique for a specific type and division: unique:type,shoes,division,10

NOT Operator

You can reverse any validator by preceding the validator with an ! (exclamation mark).

Example: !starts_with:/ will fail if the field starts with a /

Extending the Validation class

By extending the \PHPFUI\ORM\Validator class with a custom class, you can add any validator you want. A validator is defined by a method with the following signature:

validate_TESTNAME(mixed $value) : string

The TESTNAME is the name in the array of validator strings. It is passed the value of the field that needs validation. An empty string is returned on a successful validation, or an error message is returned. The error message should be as clear as possible including the expected values and the actual value passed.

Suppose we wanted a proper name rule. This rule would require the first character to be upper case and at least one following character in lower case. Here is a brute force implementation:

class ProperNameValidator extends \PHPFUI\ORM\Validator
    {
    protected function validate_proper_name(mixed $value) : string
        {
        $value = (string)$value;
        $length = strlen($value);
        $firstUpper = $hasLower = false;
        for ($i = 0; $i < $length; ++$i)
            {
            $ch = $value[$i];
            if (ctype_upper($ch))
                {
                if (! $i)
                    {
                    $firstUpper = true;
                    }
                }
            else if (ctype_lower($ch) && $i)
                {
                $hasLower = true;
                break;
                }
            }

        return $this->testIt($firstUpper && $hasLower, 'proper_name', ['value' => $value]);
        }
    }

Then our record Validation class would look like this:

class Person extends ProperNameValidator
    {
    /** @var array<string, string[]> */
    public static array $validators = [
        'firstName' => ['proper_name', 'required', 'maxlength'],
        'lastName' => ['proper_name', 'required', 'maxlength'],
        ];
    }

Translations

The validator assumes all errors will be translated, but I will leave that up to the reader to configure PHPFUI/translation

The Takeaways

Use inheritance to make something more specific. In this case, we wanted a more specific rule than the base class provided. We were able to extend the class and use it instead of the base class.

Leave classes open for inheritance if there is something that you don’t want to implement, but someone else may.

NEXT: - PHP ORM Wrapup and Benchmarks

PREVIOUS: - Implementing Active Records in PHP - Part 2

A DataObject is basically a OO wrapper around an array, but an Active Record needs to do more, like get, set and validate fields, implement relations, and of course do the basic CRUD functions. Obviously we are going to implement __get and__set magic functions, but how do we know what to get and set?

The answer is Late Static Binding and our intermediate class containing all the field information from the SQL table. I keep track of the field name (the index into the array that describes the table), and then the properties of that field, including its type, nullable and default values. So if a field is not an index in this table, it is not a valid field. I can also report on type and null errors and provide a valid default record.

Implementing Virtual Fields

Another feature of my Active Record class is support for virtual fields. You can make any virtual field you want with any relation you want. And it only takes a few lines of code. Here is the __get() function:

public function __get(string $field) : mixed
    {
    $relationship = static::$virtualFields[$field] ?? false;
    if (\is_array($relationship))
        {
        $relationshipClass = \array_shift($relationship);
        $relationshipObject = new $relationshipClass($this, $field);
        return $relationshipObject->getValue($relationship);
        }
    return parent::__get($field);
    }

A specific Record class can set up a virtual field by adding an array indexed by the virtual field name. We check to see if the field being accessed is a virtual field, and if it is an array. Then we take the first element in the array and create an object from it. We pass the current active Record ($this) and the field name it was called with.

We then call getValue() and pass it the rest of the array. Any class that derives from \PHPFUI\ORM\VirtualField be used. All you need to do is figure out what needs to be returned by getValue(). And setValue() works exactly the same way, but called by __set() instead.

And finally, we just call the parent (\PHPFUI\ORM\DataObject) __GET() and we are done implementing virtual fields! Another simple example of using inheritance with a ISA relationship.

What About Setting an Active Record Property?

Setting a variable is a bit more complicated, mostly because we need to add type checking and setting related fields in an OO manor.

First, we should implement setting virtual fields. Also simple. Just another 5 lines, so we took all of 10 lines of code (plus a few for the base VirtualField class) to implement virtual fields! Here is __set():

public function __set(string $field, mixed $value) : void
    {
    $relationship = static::$virtualFields[$field] ?? false;
    if (\is_array($relationship))
        {
        $relationshipClass = \array_shift($relationship);
        $relationshipObject = new $relationshipClass($this, $field);
        $relationshipObject->setValue($value, $relationship);
        return;
        }

Notice I don’t actually set the record for the virtual field. This is because as a generic Record object, I have no idea how to do that for a random virtual field. If the virtual field can set something, it must do it directly with the record it was passed.

Setting Related Records

While we can get related records by just looking at the field name, we need to do some more work to set a related record. Ideally we want to do this:

$order->employee = $salesEmployee;
$order->company = $purchasingCompany;
$order->update();

We can figure out how to save the relation by getting the primary key of our record and assigning that to our current record.

    $id = $field . \PHPFUI\ORM::$idSuffix;
    if (isset(static::$fields[$id]) && $value instanceof \PHPFUI\ORM\Record)
        {
        $haveType = $value->getTableName();
        if ($field == $haveType)
            {
            if ($value->empty())
                {
                $this->current[$id] = 0;
                return;
                }
            $this->empty = false;
            if (empty($value->{$id}))
                {
                $this->current[$id] = $value->insert();
                }
            else
                {
                $this->current[$id] = $value->{$id};
                }
            return;
            }
        $haveType = \PHPFUI\ORM::getBaseClassName($haveType);
        $recordNamespace = \PHPFUI\ORM::$recordNamespace;
        $message = static::class . "::{$field} is of type \\{$recordNamespace}\\" . \PHPFUI\ORM::getBaseClassName($field) . " but being assigned a type of \\{$recordNamespace}\\{$haveType}}";
        \PHPFUI\ORM::log(\Psr\Log\LogLevel::ERROR, $message);
        throw new \PHPFUI\ORM\Exception($message);
        }

We check to see if the field being set has a corresponding id as a suffix and that we are assigning an active record of the same name as our field. If the record is empty, then unset the value and return. If the record has not been saved yet, we save it now to get a primary key. Finally we assign the primary key to our current record.

If these conditions are not met, we throw a type error.

Normal Assignment

Now that we have implemented virtual fields and related records, what is left is just a normal assignment. We check if nulls are allowed and make sure the type is correct, and if not, cast it correctly. Then do the actual assignment and set the empty flag to false, since we know we set something in the record. Here is the code:

    $this->validateFieldExists($field);
    $expectedType = static::$fields[$field][self::PHP_TYPE_INDEX];
    $haveType = \get_debug_type($value);
    if (null === $value)
        {
        if (! static::$fields[$field][self::ALLOWS_NULL_INDEX])
            {
            $message = static::class . "::{$field} does not allow nulls";
            \PHPFUI\ORM::log(\Psr\Log\LogLevel::WARNING, $message);
            throw new \PHPFUI\ORM\Exception($message);
            }
        }
    elseif ($haveType != $expectedType)
        {
        $message = static::class . "::{$field} is of type {$expectedType} but being assigned a type of {$haveType}";
        \PHPFUI\ORM::log(\Psr\Log\LogLevel::WARNING, $message);
        // do the conversion
        switch ($expectedType)
            {
            case 'string':
                $value = (string)$value;
                break;
            case 'int':
                $value = (int)$value;
                break;
            case 'float':
                $value = (float)$value;
                break;
            case 'bool':
                $value = (bool)$value;
                break;
            }
        }
    $this->empty = false;
    $this->current[$field] = $value;
    }

And that is the core of an Active Record class. Obviously there are plenty of helper routines like __isset() that allows empty($object) to work correctly. And we need to implement the CRUD functions, but those are mostly creating SQL statements from our current record.

You can find the full source here.

Takeaways

Always host code out of the current class into a base class when there is nothing specific to the current class. This was the case for __set() and all we had to do was add virtual field support, then call the base class method.

Make child classes deal with any specifics. Virtual fields just defined an interface for the class. How that works is up to the virtual field implementation. We can just write to the interface.

Next time we can get into validation, which is a key component of active records.

NEXT: - ORM Record Validation in PHP

PREVIOUS: - Implementing Active Records in PHP - Part 1

Lets Get to Work!

An Active Record class has to do some basic things, like validate that a field exists and allow set and get for valid members. This sounds like a base class to me. Let’s see how we might hoist some functionality into a useful object. We need a name, so I decided on DataObject. Object was my first choice, but it is a reserved word in PHP, so DataObject makes sense, because this class is basically just the data from a query without much other logic.

First, the constructor. We would want to create an object from an array, as arrays are returned natively from the PDO interface.

class DataObject implements \ArrayAccess
    {
    public function __construct(protected array $current) {}

We have now defined how to create an object with a property of $current. And since we have constructed from an array, it would be nice to support array syntax on our new object.

Enter ArrayAccess

ArrayAccess is a standard PHP interface. And to implement it, we just need to implement the following methods:

public offsetExists(mixed $offset): bool

public offsetGet(mixed $offset): mixed

public offsetSet(mixed $offset, mixed $value): void

public offsetUnset(mixed $offset): void

Like this:

    public function offsetExists($offset) : bool
        {
        return \array_key_exists($offset, $this->current);
        }

    public function offsetGet($offset) : mixed
        {
        if (\array_key_exists($offset, $this->current))
            {
            return $this->current[$offset];
            }
        throw new \PHPFUI\ORM\Exception(self::class . " {$offset} is not defined");
        }

  public function offsetSet($offset, $value) : void
        {
        if (! \array_key_exists($offset, $this->current))
            {
            throw new \PHPFUI\ORM\Exception(self::class . " {$offset} is not defined");
            }
        $this->current[$offset] = $value;
        }

    public function offsetUnset($offset) : void
        {
        unset($this->current[$offset]);
        }

We might also want to get an array out of our object:

    public function toArray() : array
        {
        return $this->current;
        }

We might also want to add a few more methods to match standard PHP functions such as empty() and isset().

    public function empty() : bool
        {
        return ! \count($this->current);
        }

    public function isset(string $field) : bool
        {
        return \array_key_exists($field, $this->current);
        }

And of course, we want to set fields in our object:

    public function __set(string $field, mixed $value) : void
        {
        if (! \array_key_exists($field, $this->current))
            {
            throw new \PHPFUI\ORM\Exception(self::class . " {$field} is not defined");
            }
        $this->current[$field] = $value;
        }

Notice for get and set type functions, we throw an exception. Why do we do this? Simply to enforce type safety in our class and program. If we allow arbitrarily setting of any value, then we don’t have control of our destiny. We are allowing anything, like a normal array. But we want some order to our madness. So we insist that if we set a value in our object, it has to exist. The same thing applies to getting a value out of our object. If the value does not exist, that is a problem, and we throw and exception.

But since we are doing an Active Record model, we also want to support relations in the database.

What is a relation?

A related record is just that. This record is related to another record. Just like you are related to your mother and father (your parents), you are also related to your siblings (sisters and brothers) and your children. There is a direct connection between you and your parents, brothers, sisters and children. In a database, these relations are defined by the schema, rather than some genetic DNA. At the basic level, a related record could be a parent, sibling, or child. The database schema determines what is what. But at a basic level, an ID that refers to another table is a related record. It could be a parent, sibling, or even child (but probably not, as you can have multiple children, but there is only one ID), but this depends on your database structure.

In my ORM, I decided to automatically relate any field that ends in ‘Id’. So the memberId field would be the related record to the current record with a type of Member in the member table.

Implementing Related Records

The work is done in the __get magic method:

    public function __get(string $field) : mixed
        {
        if (\array_key_exists($field, $this->current))
            {
            return $this->current[$field];
            }
        // could be a related record, see if has a matching Id
        if (\array_key_exists($field . \PHPFUI\ORM::$idSuffix, $this->current))
            {
            $type = '\\' . \PHPFUI\ORM::$recordNamespace . '\\' . \PHPFUI\ORM::getBaseClassName($field);
            if (\class_exists($type))
                {
                return new $type($this->current[$field . \PHPFUI\ORM::$idSuffix]);
                }
            }
        throw new \PHPFUI\ORM\Exception(self::class . " {$field} is not a valid field");
        }

First we see if the key exists. If so, we are done and we just return it.

But because it does not exist, it might be a related record if it ends with our idSuffix (which I make user configurable for added flexibility). We simply append the id, then check if that field exists. If it does, then we probably have a related record. First we normalize the name to our record namespace (also user configurable), then see if the class exists. If it does, then it is related record!

Then we can just new the class with the value of our id, since our Record class will construct from an int as a primary key, and then return it. That is it, we are done! Of course if the member field or class does not exist, we throw an error.

So What Did We Just Build?

We built a basic class (DataObject) that converts an array into an object with object semantics, ie. $object→property in addition to $object[‘property’] syntax of an array. Since it constructs from an array, now we have an object that validates on getting and setting members (which arrays do not), works like an array, and also implements related records. It turns out we need all this functionality for our Active Record class. But that is for next time.

Takeaways

• Always validate access. Normal PHP classes now do this by default, but we should also implement it in any code we control.

• Always throw exceptions for programmer errors. Accessing an invalid field is a programming error (not a user error), and the developer should be immediately informed.

• Add useful functionality early in the class hierarchy, as it will simplify child classes.

• Implement useful interfaces such as ArrayAccess if it makes sense.

NEXT: - Implementing Active Records in PHP - Part 2

PREVIOUS: - Late Static Binding in PHP

The Problem with Eloquent

Eloquent is the ORM for the hugely popular Laravel PHP framework. Unfortunately it is a poorly designed Active Record class. The basic problem with the Eloquent Active Record is the reliance on class member definitions of the record. Each instance of an Eloquent Active Record class carries the entire definition of the record model. This is a glaring error in the design. A basic principal of Object Oriented Design is to factor out common properties to a base class. While Eloquent does that (you don't have to implement the common logic in each class), it forgets that every instance of an Active Record model is the same in terms of properties of record of the table. You don't need to track the same thing in multiple objects. You only need one copy. That sounds like a perfect use case for static! By definition, static members of a class are global to all instances of the class. So if you have a model of an SQL table, you know all instances of that class refer to the same table and have the same field properties. This is a text book definition of where you use a static member to represent the properties of a class. So as a result, a collection of Eloquent Active Records contains duplicated data that is the same for each instance. This is clearly wrong and has still not been corrected after all these years!

But how can we have the same static members that define a record be different for all the different records in a database? For example, if we implement an ActiveRecord class and then have child classes like Invoice and InvoiceItem, both of which are ActiveRecord classes, how can make the static data different for each class and not impact all instances of classes derived from ActiveRecord?

Enter Late Static Binding

Whoa! Late Static Binding? What is that? Sounds complicated! Actually it is pretty simple and has been in PHP since 5.3. In PHP, there are two reserved words that seem to do the same thing, but don't. They are self and static. You have seen these before:

class Base
    {
    public static string $value = __CLASS__;
    public function asStatic() : string
        {
        return '::static = ' . static::$value . "\n";
        }
    public function asSelf() : string
        {
        return '::self = ' . self::$value . "\n";
        }
    }
class Guardian extends Base
    {
    public static string $value = __CLASS__;
    public function mySelf() : string
        {
        return '::myself = ' . self::$value . "\n";
        }
    public function myParent() : string
        {
        return '::myparent = ' . parent::$value . "\n";
        }
    }
class Child extends Guardian
    {
    public static string $value = __CLASS__;
    public function mySelf() : string
        {
        return '::myself = ' . self::$value . "\n";
        }
    public function myParent() : string
        {
        return '::myparent = ' . parent::$value . "\n";
        }
    }

The key words self and static seem to be the same, but are very different, and when combined with late static binding, produce a very elegant solution for an Active Record class. The self keyword indicates to resolve to the value of the member of the current class, while the static keyword resolves to the most derived instance of the static member. So in the above example, if we call asSelf(), we get the $value of the class where asSelf is defined. If we call asStatic(), then we get the most derived $value class and not where asStatic was declared in the class Base. The static keyword returns the value of the most derived child class, while self returns the value of the static variable in the current class scope. You can see the mySelf() method returns the value of the static member that the current class was initialized to, and not the base or more derived class.

Here is the output to demonstrate how it all works:

Base::static = Base
Base::self = Base
Guardian::static = Guardian
Guardian::self = Base
Guardian::myparent = Base
Guardian::myself = Guardian
Child::static = Child
Child::self = Base
Child::myparent = Guardian
Child::myself = Child

And that is the "trick" to late static binding. The last derived class that declares a static member is the winner of how it should be initialized. So we can declare a static member in our base class of ActiveRecord, but it gets initialized by the last and final derived class. We can then have the ActiveRecord class access static members knowing that the values are really from the final child class. This way we have a generic static member we can rely on to get the final correct information for the final derived class. And since this information is static, it only appears once in memory, instead of every single instance of the class.

Leveraging Late Static Binding

In an Active Record ORM, one of the biggest problem is tracking database changes. This is normal handled by a migration system that handles all the database changes needed. But we also have to manage the initialization of the Active Record classes that we need to interact with to use the ORM.

One approach is to determine all this information at run time. While that is possible, it is also slow, as this has to be done EVERY time the PHP script executes. Instead, we could put this information into a class once, then load that class when needed to access a corresponding record in the database. The problem becomes we either have to modify source code, or load the information from some sort of ini file. In looking at the different alternatives, I decided to define the table structure in code. This has the big advantage of absolutely the fastest load time of any of the three approaches, as it is native PHP with no need to access any external resources.

The problem with the modify the code approach when the database changes is you have to deal with generating source code and not overwriting user code. While you can use special delimiters in the source code, this is messy and error prone. A better approach would be to use late static binding and generate a static initialization class! This class would not need to be user modified, since it only contains SQL schema information and no user logic.

Here is how the class hierarchy looks:

• \PHPFUI\ORM\Record

  • \App\Record\Definition\Invoice

    • \App\Record\Invoice

The \PHPFUI\ORM\Record class is the library class that has all the logic of how to implement an active record. The \App\Record\Definition\Invoice class has the static information describing the structure of a record in the table. This class can be automatically generated with PHP code. And finally the \App\Record\Invoice has any logic needed that is custom to a specific Invoice. By extending from \App\Record\Definition\Invoice, we get all the information about what fields are in the active record class, and by extending from \PHPFUI\ORM\Record, we have full Active Record functionality. And when the database changes, we only have to regenerate \App\Record\Definition\Invoice with some standard PHP, and possibly make changes to \App\Record\Invoice if the change was substantial.

Takeaways

• Late Static Binding "inherits" static members from the most derived child class.

• Isolating static initialization from custom code makes it easier to update.

• Separate out members that are common to all instances of the class into statics.

• Classes should only contain member properties that are unique to that object and not the class in general.

NEXT: - Implementing Active Records in PHP - Part 1

PREVIOUS: - Implementing Active Tables in OO PHP

The Base SQL Functions

There are four basic things you can do with a table, SELECT, UPDATE, INSERT or DELETE records. So let's start writing code:

public function update(array $variables) : static;
public function delete(bool $allowAll = false) : static;
public function insert(array $records, string $ignore = '') : static;

This is all pretty simple. The update statement is simply passed an associative array with the field name and value. The delete statement only has a fail safe "don't delete the entire table by mistake" flag. And insert just inserts an array of records and can ignore duplicates if needed.

Notice I did not include the SELECT method. Why? Because we need more flexibility than a single return type to select things from the data. I previously described ArrayCursors, DataObjectCursors and RecordCursor. So while update, delete and insert don't return things to iterate over, select statements do, so we need to treat them a bit differently. All these methods are effectively SELECT statements:

public function getArrayCursor() : \PHPFUI\ORM\ArrayCursor;
public function getDataObjectCursor() : \PHPFUI\ORM\DataObjectCursor;
public function getRecordCursor() : \PHPFUI\ORM\RecordCursor;
public function getRows() : array;

Select What?

What is a Select statement, but simply a list of fields you want to select. By default we can be lazy and use *. But if we wanted to get more precise, it is easy to add things to select:

public function addSelect(string | object $field, string $as = '') : static;

If the $field is string, we can simply escape it. If it is an object, we can take the string representation of the object and use that (more on this later). And the $as parameter is rather obvious. We can call addSelect() multiple times to add multiple fields. All fairly simple.

Where Art Thou

With the exception of insert, we probably need to know more about what to update, delete or select. In SQL we can control that with the where clause.

public function setWhere(?\PHPFUI\ORM\Condition $condition = null) : static;
public function getWhereCondition() : \PHPFUI\ORM\Condition;

Notice I am using my previously constructed Condition class for where, because that is what the where clause is, a condition! I can also get the currently set condition and then add to or modify it if I wanted. Now your are starting to see the power of an OO Active Table design, where I can modify what was previously set without having to deal with constructing SQL statements by hand in text. And remember, conditions can be as complex as you want. They fully nest! We can repeat the exact same logic for the HAVING condition. The power of OOP!

Do the Easy Stuff First!

An aside here: I always do the easy stuff first. If I planned on something taking a week and involving 10 pieces that need to done, I will knock off the easy stuff first. Why? Because when you have to report progress, it is always easier to say you have completed 70% of the project in 2 days, rather than doing the hardest part first and having it take 2 days, and only report you are 10% done.

Easy Peasy (Limits and Pagination)

Another thing we might want to do is limit the query:

public function setLimit(int $limit = 20, ?int $page = null) : static;
public function setOffset(int $offset) : static;

Notice here we are providing a higher level paging service than SQL provides by default. Since we can specify a page, we can think in terms of a paginated dataset, rather than having to compute the offset by ourselves, which of course we can still do.

Easy Peasy Part II (Order By)

Ordering is another easy thing to add to our Active Table:

public function addOrderBy(string $field, string $ascending = 'ASC') : static;
public function setOrderBy(string $field, string $ascending = 'ASC') : static;

Notice we have addOrderBy in addition to setOrderBy. setOrderBy will overwrite the existing ordering, where as addOrderBy will just add another order clause to the existing ordering clauses. addGroupBy and setGroupBy work exactly the same way.

Easy Peasy Part III (Group By)

Can't get much simpler than this:

public function addGroupBy(string $field, bool $rollup = false) : static;
public function setGroupBy(string $field, bool $rollup = false) : static;

Note the naming pattern here. Add vs Set. Add methods add to the existing values, while Set methods clear the existing values and start fresh with the new value.

Unions Jack

Unions are data sources from another query with the same column definitions. Since we already have a way to express a query (the Table class itself), we can easily add support for unions.

    /**
     * Add table for union.
     *
     * @param bool $any if true, adds all records from query, defaults to distinct records only
     */
    public function addUnion(\PHPFUI\ORM\Table $table, bool $any = false) : static;

Joins, finally!

Of course the elephant in the room is how do you implement joins? Joins are probably the most common and complex thing in SQL statements. Joins have four basic properties. The table we are joining, the condition we are join on, the type of join, and finally the AS clause to make the join unique if needed.

    /**
     * Add a join with another table
     *
     * @param string $table name of the table to join, case sensitive
     * @param string | \PHPFUI\ORM\Condition $on condition.  If string, name of field on the $table.  Defaults to table name appended with Id. Or \PHPFUI\ORM\Condition for complex joins
     * @param string $type of join
     */
    public function addJoin(string $table, string | \PHPFUI\ORM\Condition $on = '', string $type = 'LEFT', string $as = '') : static;

Obviously we need the table name to join, nuff said. But what to join on? A Join has a condition, and lucky for us, we have a class for that. But what if we want to simplify common joins? Often a join is on the same field name in both tables. Even more often is the primary key of the current table is the field you want to join with the other table. This works for both child and related records. For example, if we had a membership table with one or more members per membership, we could simply just join on the member table and we could automatically assume we are joining on membershipId. Or we could pass the common field name as a string. But if we wanted to get fancy, we could simply make a Condition and use that. After all, we did build a Condition class for situations just like this. Again, the power of OO strikes again.

Finally we have the type of join (LEFT, RIGHT, INNER, OUTER, etc) and an AS alias if we need it.

Odds and Ends

One of the things we need to do with SQL statements is have access to functions and other things that might be needed in a condition or select. But how can we distinguish between an SQL field that should be escaped and a function call that should not be escaped. The answer is simple. We default strings to the most common case, which is column names and escape them, then use a Literal object to wrap things that are not to be escaped. This puts the burden on the developer to do the right thing, but by default, we escape fields, which will be safer, and assume the developer will do the right thing when they use the Literal class.

class Literal implements \Stringable
    {
    public function __construct(private readonly string $name) {}
    public function __toString() : string {    return $this->name;    }
    }

As you can see, the Literal class simply does not do anything to the string, yet allows us to pass a string directly into the SQL output.

Another thing we might want to do is have an explicit Field class. Instead of a simple literal, we can use the Field class to correctly escape a field.

class Field implements \Stringable
    {
    private string $fieldName = '';
    public function __construct(string $name, string $as = '')
        {
        $parts = \explode('.', $name);
        $dot = '';
        foreach ($parts as $part)
            {
            $this->fieldName .= $dot . '`' . $part . '`';
            $dot = '.';
            }
        if ($as)
            {
            $this->fieldName .= ' AS `' . $as . '`';
            }
        }
    public function __toString() : string
        {
        return $this->fieldName;
        }
    }

Implementation

I have just been covering the interface for an Active Table class, but you can find the full implementation here.

Takeaways

• Objects are useful for adding unique behavior. We saw this with the Literal and Field classes.

• Look for parts of your problem that are the same in multiple places. This is a class example of where a class will help you encapsulate a concept, witness the Condition class. We used it for the WHERE, HAVING and JOIN clauses.

• Match the method name to the action you want to perform on the object. See update(), delete() and insert().

• Use Add and Set method prefixes to suggest how to use the class.

• Do the easy stuff first. Often you can continue to think about the more complex parts of the problem in the background as you pound out the simple stuff.

NEXT: - Late Static Binding In PHP

PREVIOUS: - Modeling SQL Conditions in OO PHP

Operators

SQL has the standard operators we all know and love, basically less than, greater than, equal and not equal. But also AND, OR, NOT, LIKE and IN to name some more common operators.

A common solution in PHP ORMs tends to look something like this:

$select->where('id', 123);

Or even

$select->where('status', '=', 'active');

Since = is probably the most common use case for an operator, I decided to make it the default. No sense in having to always specify the equal sign when 90% of the use cases will use an equal expression.

I also wanted some type checking to avoid typos and facilitate static analyzers like PHPStan. A string literal is impossible to type check statically and it is always best to detect typos as soon as possible. So I came up with the following list of operators and added them to the Operator namespace: Equal, GreaterThan, GreaterThanEqual, In, IsNotNull, IsNull, LessThan, LessThanEqual, Like, NotEqual, NotIn, NotLike

If you combine the above with the logical operators: AND, OR, AND NOT, OR NOT, you start to get close to OO expressions. But how to express parentheses you inevitably need to use to make your logic work?

Parentheses

In deciding to write my own ORM, I needed to represent conditional expressions that would allow me to easily create understandable conditions for the WHERE, HAVING and JOIN clauses. The biggest issue was how to model the nesting of conditions. If all of your conditions are simple AND clauses, life is easy, but as soon as you get to an OR condition, things get complicated fast. For example, take the following condition: purchasedDate='2024-02-01' AND lastName LIKE '%robert%' OR firstName LIKE '%robert%' We clearly don't want anyone with a firstName of Robert, we want either firstName or lastName to contain Robert and have a purchasedDate of 2023-02-01. So we would put parenthesis around the like clauses like such: purchasedDate='2023-02-01' AND (lastName LIKE '%robert%' OR firstName LIKE '%robert%').

So how do we represent parenthesis in an expression? The answer turns out to be a Condition is always parenthesized. Adding a Condition object to another Condition object will add parenthesis around the added object. Also, extra parenthesis around a single condition will never hurt anything, as SQL knows how to deal with parenthesis even when they are not required.

So a Condition can have any number other Conditions added to it, each glued together with one of the logical operators, AND, OR, AND NOT, and OR NOT.

So here is how we would implement our example expression:

$searchName = '%robert%';
$condition = new \PHPFUI\ORM\Condition('purchaseDate', '2024-02-01');
$nameCondition = new \PHPFUI\ORM\Condition('lastName', $searchName, new \PHPFUI\ORM\Operator\Like());
$nameCondition->or('firstName', $searchName, new \PHPFUI\ORM\Operator\Like());
$condition->and($nameCondition);

This evaluates to the following (with substitutions made):

`purchaseDate` = '2024-02-01' AND (`lastName` LIKE '%robert%' OR `firstName` LIKE '%robert%')

Outputting Our Expression

Since we are writing code that needs to escape user input, we actually don't want to just return a text string with the fields inserted in plain text as above. The PDO object does this for us, so let's leverage that functionality and get two things, the string representation of the expression with placeholders instead of string values, and also the values we need.

Obviously, __toString would be a good match for returning the plain SQL. Then we can return a matching array of values used in the expression with getInput()

You can find the code and documentation here.

Conclusion

Objects have provided great value for us in this situation. First, since we can easily nest objects, we have an elegant solution to the parenthesis problem. We can also save the state of the expression and pull out the text representation and substituted values for use later in the program. We have also enabled some basic static and dynamic type checking.

Another win for OO design!

NEXT: - Implementing Active Tables in OO PHP

PREVIOUS: - PHP Database Cursors

Three types of Database Cursors

While I want to implement a database cursor on an Active Record class, often database queries will return more information (think JOIN) than an Active Record class (which only models one record from a table) can hold. Since PHP highly leverages associative arrays, it makes sense to model a database cursor returning an associative array, as our CSV reader does. But arrays are kind of limited in what they can do. A more flexible approach would be to return an object, but not a fully typed checked Active Record. This will make the code a bit more generic and extensible. We can also implement ArrayAccess on the DataObject that the cursor will return, so now we have something that acts like an array, and has more functionality than a basic array but is not an array.

So our three types of database cursors will be ArrayCursor, DataObjectCursor and RecordCursor.

Hoisting Out Common Code

One of the design principles of OO design is to hoist common code out of a class and put it in the parent class, where it can be used by multiple children of the parent class but can be tweaked in the child class. So this calls for an abstract parent class, one that can be inherited from, but not instantiated as an object directly.

Let's start coding!

abstract class BaseCursor implements \Countable, \Iterator

The base cursor class needs to implement Iterator, but also Countable, since we want the cursor to mimic an array, which is countable.

Next Step: Common Data

protected ?int $index = null;
private ?int $count = null;
private ?\PDOStatement $countStatement = null;
private ?int $total = null;
private ?\PDOStatement $totalStatement = null;

Our cursors have an index, which will be the zero-based record number, so we can use the $index property for that.

We also need to count the number of records in the query, so we will cache that number in the $count property. Notice that count is the number of records returned by the query affected by the limit clause. This is the expected number of records the specific query will return, which could be less than the limit clause if there are fewer records matching the search criteria than the limit, or the last query in a paginated query which is almost always less than the limit clause.

Another property that would be nice to have is the total number of records that matched the query. This is the $total property.

We also have some internal housekeeping to keep track of the queries for the count and total records. These are PDOStatements we will need to get from the Active Table class that knows this information.

Notice the only property where that is not private is $index. This is because it is useful to child classes, while the count and total related properties are private, as the child classes will have nothing to add, as all this information is generic and does not change for the child classes.

Construct and Destruct

public function __construct(protected ?\PDOStatement $statement = null, private readonly array $input = [])
  {
  }

public function __destruct()
  {
  $this->statement?->closeCursor();
  $this->index = -1;
  $this->total = null;
  $this->count = null;
  }

In PHP 8.0, we can promote constructor parameters to properties, so now we have the basic PDOStatement which represents the query and the data associated with the query. $statement is needed by child classes, so it is protected, but $input is only used by the base class, so it is private. This prevents child classes from meddling in our business!

We also implement a destructor. In PHP, people tend to not implement destructors simply because PHP throws everything away at the end of the execution of a server request. But in our case, we use the destructor to manage a resource, which is the PDO cursor that will see initialized later in the code. Managing resources is the primary reason for destructors. If your class is not managing a resource (open file, open connection, or anything with an open / close functional interface returning a handle), then you probably ignore destructors. But to avoid SQL connection leaking, we need the destructor to automatically release the open handle.

We also reset some internal states, but this is more belt and suspender code. It is a flag to the next developer that this object is now done.

The Easy Stuff

Since we are an abstract class, we need to define the entire interface, but we may not want to implement a default implementation. Let's get the easy stuff out of the way:

abstract public function current() : mixed;
abstract public function next() : void;
abstract public function valid() : bool;

The current(), next() and valid() methods all relate to the type of object we are iterating over, so there is no generic implementation we can use. An array is created differently than an ActiveRecord, which is probably different from a DataObject. They have different ways to validate and return the current record. So we declare them as abstract and leave the implementation of all these to the child class to do what is best for them.

Common Generic Code

There are a couple of things that are generic to database cursors, and those we can add to the base abstract class:

protected function init() : void
  {
  if (null === $this->index)
    {
    $this->rewind();
    }
  }

public function rewind() : void
  {
  if (! $this->statement)
    {
    return;
    }
  $this->index = -1;
  $this->statement->closeCursor();
  $result = \PHPFUI\ORM::executeStatement($this->statement, $this->input);
  if ($result)
    {
    $this->next();
    }
  }

public function key() : int
  {
  $this->init();
  return (int)$this->index;
  }

The first thing we see here is the init() method. Since we constructed our object without doing anything other than setting some values, we have not done a query to the database. We may never do a query to the database depending on the logic of the system using our class, but we want to make sure we are initialized correctly if our user decides to get something from the cursor. I use an init function to wrap all this and delay initialization if possible. init() simply checks for the initial value of $index and calls the rewind method, which does the actual work of executing the query. We will call init anytime we need to make sure the data has been initialized. It is a low overhead call, as it simply checks the value of $index and returns if initialized.

The rewind() method is where all the work happens. First, we see if we have a valid statement. If we don't have a valid $statement property, we don't crash, we simply don't iterate. Then we set the $index property to -1, as are going to start (or start over) reading data, and the first record is zero-based, and next() will increment the index later.

We then close the current cursor, since we are going to make a new one. If no cursor has been opened, this call does nothing, which is fine with us.

Next, we call exectuteStatement() to run the statement and log any errors for us. If no errors, we call next() to do the actual work of getting the first item from the initial query.

And finally, the key() method just makes sure we are initialized and returns the current index.

The Hard Stuff

Finally, we get to the harder part of the class, keeping track of the count of records the cursor is iterating over, and the total number of records of an unlimited query.

We will do the total logic first, as it is the easier of the two:

public function setTotalCountSQL(string $totalSql) : static
  {
  $this->totalStatement = \PHPFUI\ORM::pdo()->prepare($totalSql);
  return $this;
  }

public function total() : int
  {
  if (null === $this->total && $this->totalStatement)
    {
    if ($this->totalStatement->execute($this->input))
      {
      $this->total = (int)$this->totalStatement->fetch(\PDO::FETCH_NUM)[0];
      }
    }
  if (null === $this->total)
    {
    $this->total = $this->count();
    }
  return $this->total;
  }

First, we need to allow the ORM to set the query for the cursor. The cursor does not know about the query, it just iterates over a result set. So we can get the total record count from the ORM, as the ORM knows how to do this, whereas the cursor does not. We prepare it and save it for later.

When total() is called, we check to see if we have not executed the total query yet. This delays execution in case our user does not care about the total number of records the query returned. We then execute the query and cache the result in case our user requests it again. If we still don't have a valid total, we default to the count.

And finally, for the count, we do something similar, except we can set the query count directly if needed. This can be used to optimize a query if we have computed the count for another reason.

public function count() : int
  {
  if (null === $this->count && $this->countStatement)
    {
    if ($this->countStatement->execute($this->input))
      {
      $this->count = (int)$this->countStatement->fetch(\PDO::FETCH_NUM)[0];
      }
    }
  if (null === $this->count)
    {
    $this->init();
    $this->count = $this->statement ? $this->statement->rowCount() : 0;
    }
  return $this->count;
  }

public function setCountSQL(string $limitedSql) : static
  {
  $this->countStatement = \PHPFUI\ORM::pdo()->prepare($limitedSql);
  return $this;
  }

public function setQueryCount(int $count) : self
  {
  $this->count = $count;
  return $this;
  }

Takeaways

• Host common code to the parent class.

• Use abstract classes to share common code.

• Declare abstract methods for anything you need the child class to implement.

• Make properties protected if they are useful to child classes.

• Properties that are controlled and depended upon by the current class should be private.

• The fully commented and prettified code can be found here.

NEXT: - Modeling SQL Conditions in OO PHP

PREVIOUS: - Active Table Design Pattern

More Requirements

One of the things you need to do with databases is query and update them, or why else have a database? The Active Record is a well-known design pattern and even has its own wikipedia page. The Active Record pattern only deals with one record. A Database Cursor can iterate over an effective collection of active records, but how can we get the original collection to feed to the database cursor? In SQL databases, what we are looking for is a SELECT statement that returns all records matching the criteria (where clauses, limits, orders, etc). Instead of selecting those records, we might want to update them in mass, or even delete them.

So we need a way to manipulate a SQL table and perform selects, updates, deletes and inserts, the four basic things you can do with a database.

Enter Active Table Design Pattern

Just like we can manipulate an Active Record (change field values, save it, delete it, update it, and insert a new one), we should be able to do the same thing with an SQL table. Think about a table as something that has properties and can perform actions on records. This sounds like a perfect fit for an object to me. Here are the actions we would want to perform on a table:

• SELECT

• UPDATE

• DELETE

• INSERT

But we would also want to limit some of the above actions to just the records we are interested in. So we would need to be able to set the following:

• WHERE and HAVING clauses

• LIMIT clause

• ORDER BY clause

• JOINs

• UNIONs

• and others!

The Use Case for Active Table

One of the things most database apps do is to allow the user to specify how they want to see the data. Sorting, columns to display, conditions for which record to display, etc. If we have an easy interface to the table object, it is fairly easy to modify the table object to do what the user wants. So dealing with a user becomes setting properties on the table, then performing the action the user wants. Sounds like a good match to me.

And that is a Design Wrap!

So now we have figured out the requirements for an ORM. As I have said before, I was unable to find an existing ORM that did everything I would like to have in an ORM. I was also not happy with the complexity of some of the existing solutions. Complexity is EVIL and tends to slow things down as it requires more memory and execution time to implement. Given two separate designs that do the same thing, the better design is always the one with fewer parts. This is one of the fundamental rules of engineering.

Final List of Requirements

• Active Record functionality including:

  • CRUD functionality

  • Field names match table column names

  • Fields typed like table columns

  • Fields type checked

  • Field validation with understandable error messages

  • Fields with PHP class types (like Carbon)

  • Virtual Fields

  • Relationships:

    • Parent Record

    • Child Records

    • One To One

    • Many To Many

  • Per class custom logic

• Database Cursors

• Active Table functionality including:

  • SELECT

  • UPDATE

  • DELETE

  • INSERT

  • WHERE and HAVING clauses

  • LIMIT clause

  • ORDER BY clause

  • JOINs

  • UNIONs

• Support for plain text SQL queries

• Atomic migrations

• Auto generation and updating of classes

• Fast and small memory footprint

Takeaways

If you have been following along in this series, you have seen that the more you think about a problem, the clearer the solution becomes. And when you start thinking in terms of objects and actions you can perform on them, you begin to understand the power of an object-oriented design.

The primary thing to remember with any OO design is you are modeling an object with properties. You perform actions on or request things from the object. The object handles the internals of how to do things. The object tries to ensure it returns the correct results given the properties you set. The object shields how it does things from you. If you follow the object's contract (interface), then the object is free to do what it needs to work. The object can also be updated to do things in a better way without affecting things that use the object as long as it holds up its side of the contract.

Another thing to remember with OO design, is you are free to use the object outside of the OO paradigm in other places. You can still do procedural or functional programming and use objects. They are not mutually exclusive.

Next time we can start coding!

NEXT: - PHP Database Cursors

PREVIOUS: - Iterators And Database Cursors In PHP

More Requirements

One of the things you need to do with databases is query them and return records matching your query, or why else would you have a database? In PHP land we iterate over things all the time with loops, primarily foreach loops. The foreach statement can iterate over anything that implements the Iterator interface. This includes arrays and since PHP arrays are a great data structure, we tend to use a lot of arrays in PHP development. But what if what we want is not already in an array? What if it exists as a file on the disk, or records in a table? How can we use the handy foreach loop to look at all the records contained in them?

Iterator Interface to the Rescue

Fortunately, the smart folks at PHP defined the Iterator interface to allow foreach loops to interact with our custom code. Here is the definition of the Iterator interface.

interface Iterator extends Traversable {
  public current(): mixed
  public key(): mixed
  public next(): void
  public rewind(): void
  public valid(): bool
}

Let's take a look at how this OO abstraction can be leveraged for the foreach loop.

Interfaces are Contracts

The interface defines 5 methods. Here is what they do:

• current() returns the record at the current position of the iterator. This can return anything, including a scalar type, an array, an object or anything PHP can create.

• key() returns the key for the foreach loop, normally this would be the array key.

• next() moves the iterator to the next element. Notice that it does not return anything, it simply moves the current record pointer. You need to call current() again to know what the iterator is currently pointing to.

• rewind() returns the current pointer to the start.

• valid() returns true if the iterator is pointing to a real record. For an empty dataset, this would return false. Valid also returns false when the iterator hits the end of the list.

This is all a foreach loop needs to traverse a list. If we implement the interface, we can now use a foreach loop to read through any data we want. The interface defines a contract with the user. If you follow the contract of the methods and how they work, then your class will work wherever an Interface is required.

Iterators for CSV Files

Say we have a CSV (comma-separated values) file on the disk. Here is how we would read it with a CSV iterator:

$csvReader = new \CSV\FileReader('countries.csv');
foreach ($csvReader as $row)
  echo $row['Country'] . "\n";

Notice how the $csvReader looks exactly like an array. Let's number the list:

$csvReader = new \CSV\FileReader('countries.csv');
foreach ($csvReader as $index => $row)
  echo "{$index}. {$row['Country']}\n";

Here is the code behind the \CSV\FileReader:

namespace CSV;
class FileReader extends \CSV\Reader
    {
    public function __construct(private readonly string $fileName, bool $headerRow = true, string $delimiter = ',')
        {
        parent::__construct($headerRow, $delimiter);
        }
    protected function open() : static
        {
        if (\file_exists($this->fileName))
            {
            if ($this->stream)
                {
                \fclose($this->stream);
                $this->stream = null;
                }
            $this->stream = @\fopen($this->fileName, 'r');
            }
        return $this;
        }
    }

Notice the constructor takes a required file name. This makes sense since we can't read a CSV file if we don't know what the file name is. We also have two default parameters that users of our class may be interested in. The $headers boolean defaults to true and indicated the CSV file has a header row naming the columns. Most CSV files follow this format since unnamed columns tend to be confusing to people who might need to read your file. The last parameter is the delimiter character. Since CSV files are normally delimited by commas, this is the default. But some files might use another character such as a tab, this allows the user to specify an alternate field delimiter.

The other method is open() which understandably opens the file for reading since that is what we want to do with the file. Notice open() is not in the Iterator interface. This is an addition to our class that we need for it to function correctly.

But what about the 5 methods in the original interface? Where are they? How can this work?

Enter Hoisting

One of the benefits of OOP is reuse and the ability to change just the things we need, and not worry about the other parts which should just work if we follow the intended interface contracts. In this case, we hoisted all the basic Iterator methods into the parent class here:

namespace CSV;
abstract class Reader implements \Iterator
    {
    protected $stream = null;    
    private array $current = [];
    private array $headers = [];
    private int $index = 0;
    public function __construct(private readonly bool $headerRow = true, private readonly string $delimiter = ',')
        {
        $this->rewind();
        }
    public function current() : array
        {
        return $this->current;
        }
    public function key() : int
        {
        return $this->index;
        }
    public function next() : void
        {
        $this->current = [];
        if ($this->stream)
            {
            $array = \fgetcsv($this->stream, 0, $this->delimiter);
            if ($array)
                {
                ++$this->index;
                if ($this->headers)
                    {
                    foreach ($this->headers as $index => $header)
                        {
                        if (isset($array[$index]))
                            {
                            $this->current[$header] = $array[$index];
                            }
                        else
                            {
                            break;
                            }
                        }
                    }
                else
                    {
                    $this->current = $array;
                    }
                }
            }
        }
    public function rewind() : void
        {
        $this->index = -1;
        $this->open();
        if ($this->stream)
            {
            \rewind($this->stream);
            if ($this->headerRow)
                {
                $this->headers = \fgetcsv($this->stream, 0, $this->delimiter);
                }
            }
        $this->next();
        }
    public function setHeaders(array $headers) : static
        {00
        $this->headers = $headers;
        return $this;
        }
    public function valid() : bool
        {
        return $this->current && $this->stream;
        }
    protected function open() : static
        {
        return $this;
        }
    }

Notice I implemented all 5 of the Iterator methods in this parent class. The class is abstract because it is not usable by itself unless the $stream property is properly initialized. In our FileReader class, we used the open() method to initialize the $stream from a file. In the base class, we know we need an open() method, but we don't know how it will work. We don't want to force our users to implement it because there might be a case where it does not make sense for them. So we just implement a method that does nothing and can be redefined later if needed.

Also, notice we added a setHeaders() method. If you wanted to change headers at some point in processing a stream, you could do that.

The major work in this class is being performed by the next() method. Since PHP provides us with a nice line reader for CSV files, I decided to use it. fgetcsv() uses a resource stream as input, so that is why our class assumes a resource stream.

The other work done in the class is the rewind() method. Notice that it is called in the constructor to initialize the object. This guarantees the object is created correctly and in a valid state when the constructor is done. Calling other methods in your constructor is good practice as custom one-off code might get out of sync with the rest of the class if a future modification changes some behavior. This way, we know rewind will always get to the beginning of the stream and read in the first record (if it exists).

The rest of the class is straightforward code returning the current state of our reader.

Implementing other Interfaces

Since our base class deals with generic streams, what else could we iterate over? How about just a generic steam from who knows where:

namespace CSV;
class StreamReader extends \CSV\Reader
    {
    public function __construct($stream, bool $headerRow = true, string $delimiter = ',') // @phpstan-ignore-line
        {
        $this->stream = $stream;
        parent::__construct($headerRow, $delimiter);
        }
    }

That was simple! This OOP stuff is starting to make sense! Notice we only need to initialize the $stream property. We then call the parent constructor and we are good to go. Now anything that is a resource can be iterated over as a CSV file.

NOTE: I did not give $stream a type. This is because PHP has not provided a built-in type for resources due to various reasons. So we have to go with an untyped variable, which is not ideal, but it works. \CSV\Reader will probably blow up if passed the wrong thing, but it will be obvious to the developer who does not read the docs. Also, I removed the docs from the sample code to save space. You can see the full source here.

Another fun thing we can do with stream resources in PHP is convert a string into a stream. Let's see how that looks:

namespace CSV;
class StringReader extends \CSV\Reader
    {
    public function __construct(private readonly string $data, bool $headerRow = true, string $delimiter = ',')
        {
        parent::__construct($headerRow, $delimiter);
        }
    protected function open() : static
        {
        if ($this->stream)
            {
            \fclose($this->stream);
            }
        $this->stream = \fopen('php://memory', 'r+');
        \fwrite($this->stream, $this->data);
        return $this;
        }
    }

The first thing to notice is we now need the open() method, which we did not need in the StreamReader class. The reason is our constructor takes the string we want to process as a CSV. We keep a copy of the string since we know that rewind() is going to be called, and it needs the original string. We do all the magic in the open() method, which is called from the rewind() method. By doing this, we are keeping the contract of the class. The constructor rewinds the object and calls open() to make sure it is initialized correctly. The open() method does the work to convert a string to a stream.

Advantages of Iterators over Arrays

As you can see in the \CSV\Reader code, we never have more than one row of the stream in memory at one time. This is the primary advantage of Iterators over arrays. Since we don't have a large memory footprint, we can iterator over huge datasets that may not fit into memory at one time. The interface allows us to keep the semantics of an array but without the memory overhead of the array. We can take existing array logic and convert it to iterators to save memory but not have to change the logic, except for the source of the array, which is generally a very small change.

But what does this have to do with an ORM?

I originally started this post by wanting to further think about what I would want in an ORM. Database work tends to involve large datasets, and we certainly don't want to read all rows of a table into an array in memory as we can't be sure they will all fit! So the Iterator interface looks like a good solution to the problem. And this is one of the concepts lacking in most ORMs I looked at before I decided to write my own ORM. Most ORMs are repository based, which tend to be in memory collections of objects from the database. They also tend to consume huge amounts of memory because of this.

The final deciding factor is that we don't have to return an array from the current() method. We can return any object in PHP. What if that object is an Active Record? Now we can iterate over a huge dataset and do want ever we want with individual records.

There is still more ORM design work to do which I will cover next time. Till then, here are the takeaways for now. You can also follow along with the fully commented and tested code here.

Takeaways

• Interfaces define contracts. Implement the interface and you can use the class anywhere the interface is used.

• Hoist common code up to the parent.

• Think about how things are the same or different. Hoist common code to the parent class, and implement different things in the child classes.

• Add functionality where it makes sense.

NEXT: - Active Table Design Pattern

PREVIOUS: - Zen And The Art Of Class Design

zen : a state of calm attentiveness in which one's actions are guided by intuition rather than by conscious effort - Merrian Webster

In my previous posts, I discussed class design and naming conventions, so I thought I would go into more depth on those subjects and see how it applies to real-world applications. I will be using the concept of zen and not having to think about details that get in the way of what I am trying to accomplish, which is creating websites.

Functional vs Object Oriented

With a functional interface, such as the original PHP MySQL interface, you end up with huge amounts of boilerplate. For example to read a row out of a table (assuming you already have an open database connection):

// Select the row
$sql = "SELECT * FROM table WHERE id = 1";
// Execute the query
$result = mysql_query($sql);
// Fetch the row
$row = mysql_fetch_assoc($result);
// Print the row
echo $row["column1"] . " " . $row["column2"] . " " . $row["column3"];

This is not zen. We are having to deal with things at a very low level and I am concentrating on the work involved in retrieving things from the database rather than my website logic.

MySQLi Improved?

With the improved MySQLi interface, you still end up with a lot of code just to save or retrieve something. Even the "OO" version of the interface still leaves you with a lot of boilerplate.

$mysqli = new mysqli('localhost', 'my_user', 'my_password', 'world');
// Create the SQL query
$sql = "SELECT * FROM table WHERE id = 1";
// Execute the SQL query
$result = $mysqli->query($sql);
// Fetch the row from the result set
$row = $result->fetch_assoc();
// Print the row data
echo $row['column1'] . ' ' . $row['column2'] . ' ' . $row['column3'];

The "big" OO improvement here is the mysqli object ($mysqli) allows you to associate a specific instance of a database to a specific query. It still has the same level of boilerplate, just substituting OO semantics for the previous functional interface. Still not zen, too much to think about.

One of the biggest problems with any SQL interface is SQL injection attacks where passing unescaped user data could be manipulated into running untrusted code. Things get more complicated once you have to accommodate user data, which is most of the time:

$mysqli = new mysqli('localhost', 'my_user', 'my_password', 'world');
$stmt = $mysqli->prepare("SELECT Language FROM CountryLanguage WHERE CountryCode IN (?, ?)");
$stmt->bind_param('ss', 'DEU', 'POL');
$stmt->execute();
$stmt->store_result();
echo $stmt->num_rows() . " rows found.\n";

So while MySQLi improved things, it is still not a nice abstraction or encapsulation of SQL query functionality, and still not zen. While it is safe from SQL injection attacks, we are even further away from the idea of zen, since we have to deal with even more boilerplate.

Enter PDO

With PHP 5.1, the PDO class was introduced to try to make things even easier and a bit more generic.

$pdo = new PDO('mysql:dbname=world;host=localhost', 'my_user', 'my_password');
$stm = $pdo->prepare('SELECT name, colour, calories FROM fruit WHERE calories < ? AND colour = ?');
$stm->execute([150, 'red']);
$result = $stm->fetchAll();
foreach ($result as $row)
  echo "{$row['name'] has {$row['calories']} calories and is {$row['colour']\n";

We are still dealing with arrays as result sets, but clearly, we are dealing with less boilerplate code, but still no abstraction and encapsulation. It does not seem very zen, but better than the mysqli interface.

Pure OO Abstraction and Encapsulation

One of the goals of OO (object-oriented) design is to encapsulate implementation details so you can concentrate on your business logic and not have to deal with pesky details that every application has to deal with, like saving and retrieving previously stored data.

At a high abstract level, you simply want to have an object you are working with to be able to save, load, update or even delete itself. It seems these are basic properties you would want on any object. So how do we get there?

Designing A Class

When we talk about designing a class, we want to think about want we are trying to accomplish. In this case, we are talking about storing and retrieving records from a SQL database. So we want our object to represent the data structure of the table. The easiest way to think about this is for each column of the table to have a corresponding representation in our object. Ideally, we would name each field of the object to be the same as the table column names. We then have a clear one-to-one mapping of the record to the table and no room for interpretation.

Define Requirements

We previously determined we need basic CRUD (Create, Read, Update and Delete) functionality. This is a known design pattern called Active Record.

But what else might we want?

Requirements vs Nice To Have

One of the biggest decisions in class design is to know what is required of the class, and what would be nice to have. I tend to like to keep things minimal, so I only add nice-to-have things if they can be easily and trivially implemented. But the problem with class design is you want to make it flexible enough that you can accommodate new requirements without breaking older functionality. The best way to do this is to do some blue-sky thinking and see what you can do cheaply and efficiently.

Blue Sky Thinking

Let's dream a bit about what we might want and see what makes sense. Certainly, we would want to know what we are inserting is valid, so we want some sort of record validation.

Maybe we would also want to ensure data consistency for any data we insert into our table. Two examples would be US state abbreviations and zip codes. Both of these have strict known formats.

We would also want to be able to add some record-specific code if we wanted. OOP allows for doing this easily, we just want to make sure nothing we do will prevent future inheritance.

We might also want custom types rather than the 4 built-in PHP scalars (bool, int, float and string). For example, we would probably want to represent SQL types like DATETIME, DATE and TIMESTAMP with the Carbon date library.

We would also want to represent standard SQL relations in some sort of OO way. Those relationships might include, but should not be limited to:

• Parent Record

• Child Records

• One To One

• Many To Many

And how about virtual fields? We might want to show users cost per ounce, but we don't want to have to recompute this every time we change either the price or the number of ounces on a product. We can compute it 100% accurately on demand.

And type checking would also be nice to have. You don't want to assign a random string to an integer. Type checking helps the developer to spot errors quickly.

Our Requirements

I happen to know all this blue sky thinking is super easy to implement, so let's write out our requirements then we can pause and think about how we are going to implement it.

• Active Record CRUD functionality

• Field names match table column names.

• Fields typed like table columns

• Fields type checked

• Field validation

• Fields with PHP class types (like Carbon)

• Virtual Fields

• SQL Relationships

• Per class custom logic

Is there an existing package that meets our needs?

One would think it should be fairly easy to find a PHP package that would satisfy these basic requirements, but I was unable to come up with anything reasonable and currently supported. I also have some ideas about database cursors and tables that no one seems to have implemented, so I decided to write my own ORM (Object Relationship Mapper) to do everything I needed. So now I have to think about designing a class (or multiple classes) to do what I need done.

Time To Think About Implementation

And this is probably the most important part of class design. You need to think about how you are going to implement it. I find the more I specify requirements and then think about it without rushing into coding, the better design I come up with. Obviously, you can still change things as you code and will probably come up with a better implementation as you revise the code, it helps to start with a solid understanding of what you are trying to accomplish and some idea of how to make the vision a reality.

You may also want to think about how things might change in the future. Ideally, your design allows future expansion. But don't make the mistake of implementing something you don't need immediately. Think about how you might implement it in your current design, but don't actually do it. This will help shape your design decisions to be a bit more open and flexible. Often just knowing how you would implement something in the future is enough of a design. Not everything needs to be spelled out in code.

Next time we will dive into the first part of an implementation with a few more requirements and lay the groundwork for extensible classes.

Takeaways

You have to have an understanding of what you are trying to accomplish before you set out to write code. This is probably the most important aspect of designing anything, knowing where you are going.

It is important to define requirements and nice to haves so you know which direction you want to go towards. It also helps to think about future features even if you don't need them now.

Look for existing packages before you write from scratch. Many people have been solving similar problems for years. See if you can find something that works for you.

And if you need to write code, spend some time just thinking about it in the back of your mind before you start typing.

NEXT: - Iterators And Database Cursors In PHP

PREVIOUS: - Getters And Setters VS Public Access

Who Owns What?

Traditionally this has been done with Getter and Setter methods. For example, you might have a Book object and have a title, author(s), publisher, etc. In old-school OO design you would have the following methods:

• getTitle() : string

• setTitle(string $title) : self

• getPublisher() : Publisher

• setPublisher(Publisher $publisher) : self

While this gives you complete control over the object, it becomes a little clumsy to use in day-to-day programming. For example, this:

$book->setTitle('My PHP Book Title');
$book->setPublisher($publisher);

seems less user-friendly than this:

$book->title = 'My PHP Book Title';
$book->publisher = $publisher;

In this case, public access for the title and publisher seems to make sense. The Book object exists so we can manipulate it, and if we need to change the title, then we want to do that easily since we know what the title should be and not the Book object. In this sense, the user owns the content of the title, while the Book class is only responsible for storing whatever the user provided.

Objects Are Types

Classes also provide type safety by their mere existence. PHP has long supported using class type information on method and function calls. This helps ensure your program is working as expected. Notice the difference between these class interfaces:

public function setPublisher(int $publisherId) : self;

verses an object oriented approach:

public function setPublisher(Publisher $publisher) : self;

By requiring a class object of type Publisher we ensure we are not assigning a random integer to the publisher. By exposing the underlying type of how we are going to store the publisher relationship, we have pushed in implementation detail (we are storing a publisher as a relation) into the face of our clients. Now our users have to deal with a specific detail of how our database works. And at the same time, we have made things less robust and more error prone.

Make Objects Type Safe

Notice the class is automagically storing the relationship of the publisher. We are providing an object interface to the publisher, and not just a string. This is because a publisher probably has other properties we want to track elsewhere in the database, like how to reorder a book! In this case, we are not storing an integer pointing to the primary key of the publisher table, but rather the publisher object itself. While the setPublisher method makes this clear, in PHP, the class can enforce this itself with magic methods (more on this next time). This makes the class more type-safe since we can't assign a book id to a publisher id and create a database inconsistency.

The more you leverage treating classes as types and hide the implementation details from the user of your class, the more readable and reliable your code becomes. An example of why this is worth doing might be making the data you reveal to users of your website more anonymous. If we were to expose integer ids for records in a URL, like /member/57292, we can deduce there are probably 57292 users and that user 57291 also exists. But if we decide to go with a GUID type of primary key, then we can obfuscate this information from the public view and other users. And if we only put classes into our interface, the users of our class won't have to deal with us changing the implementation and having to deal with the fact that we have pushed an implementation detail into their faces.

Use Plural and Singular Correctly

Now let's consider the case of authors. While most books have just one author, enough books exist with multiple authors, so our Book class needs to deal with that. And while we know what authors are associated with a book, the Book object only needs to know that it needs to store and retrieve multiple authors on a book.

In this case, a public list of authors would be an extremely bad idea. While you could add an array of authors as a public property, who is to say what is in that array? In PHP land you can add anything to the array, not a great idea if you expect them to all be authors!

So the Book class needs to control access to the list of authors. Since we are dealing with more than one author (as opposed to the title where we only have one per book), we should use the plural form. This indicates to the class user that there can be multiple authors per Book. For example:

public function addAuthor(Author $author) : self;
public function removeAuthor(Author $author) : self;
public function getAuthors() : iterable;
public function setAuthors(iterable $authors) : self;

This allows us to add or subtract any individual author, but also get a list of all authors and set the list of authors. Why would we want to set the list of authors? To provide an order of authors. Most books will either list the authors alphabetically, by importance, contributions or agreement.

Notice we have not set how the authors are stored in the Book class. As a user of the Book class, we don't care how the authors are stored, just that we want to store these authors and get them back in the future, in the same order we added them. This is solely the responsibility of the Book object and not the user of the class, so we wrap this functionality to take control from the user, but allow the user to do what they need.

Provide Useful Methods

A class may present other relationships it is aware of as a convenience to the user. For example, an Author class may present the following methods:

public function books() : iterable;
public function publishers() : iterable;

The books() method would return all books by the current author. Same for publishers. While you could easily get this information from the database, the Author class makes it easier to use without cluttering up your code with random database calls. For example:

echo "Other books by {$author->fullName()}:\n";
foreach ($author->books() as $book)
  {
  echo $book->title . "\n";
  }

While the above example is trivial and will list all the books for the author, and probably the current book you are viewing, it does show the simplicity of an object-oriented design. Here are some other ideas for getting the author's books:

public function mostRecentBooks(int $limit = 5) : iterable;
public function mostPopular(int limit = 5) : iterable;

Notice what we have implicitly done here. We have put the logic of getting the most recent and most popular books by an author in one place. So when we need to change this logic, we can change it in one place and not have to track down separate database queries scattered throughout the code base.

Takeaways

When designing classes, think about who is responsible for the data in the class. If the user of the class is the arbiter of the data, then let the user of the class deal with it directly. If the user of the class should not concern themselves with something, protect the inner workings from outside forces.

Classes are types. The class should enforce proper usage of itself and provide functionality for its users.

Provide type safety when and where ever possible. Adding a public array to a class is almost always a bad idea. Typing a public property is a good idea, but make sure you enforce the type.

Name things correctly. If something has multiple versions, use the plural form of the word, otherwise keep it singular. This helps users understand the class.

Provide useful methods to users of your class.

NEXT: - Zen And The Art Of Class Design

PREVIOUS: - PHP Inheritance Explained

Monopoly Dice

If we were to model the board game Monopoly, we would certainly want some Dice. Monopoly dice are different from Yahtzee dice and certainly different from Dungeons and Dragons dice. So let's model Monopoly dice. We can use our Dice class, but extend it a bit to make it more specific. First, we know we want the standard six-sided die, and second, we need two of them. We also might want to know if the dice have rolled doubles, as that makes a difference in Monopoly. And we want the total value of the two dice to compute how far we need to move.

namespace Monopoly;
class Dice extends \Dice
  {
  public function __construct()
    {
    $this->add();
    $this->add();
  }
public function doubles() : bool
  {
  $values = $this->values();
  return $values[0] == $values[1];
  }
public function value() : int
  {
  $values = $this->values();
  return $values[0] + $values[1];  
  }
}

The first thing we do is declare an appropriate namespace.

Next, we construct our object with two default ADie classes, which is the six-sided die.

And then we implement the two methods we want, doubles() and value(). One could make an argument that the value() method should be in the base class, and that would not be wrong. But for this example, we will add it to this class. Notice we did not have to worry about the roll() method. It works exactly as it needs to, and we don't have to adjust its behavior by overriding it.

We have now successfully inherited the base Dice class to extend it for Monopoly. We used inheritance because a Monopoly\Dice is a Dice.

One thing we did not implement in the Monopoly\Dice class is going to jail. Remember, three doubles in a row lands you directly in jail without visiting the next property. Why not? Seems logical. But you have to understand that three doubles in a row is a rule of the game in Monopoly, and not a property of the dice. Doubles is a property of the dice, while going to jail is not. So we would implement going to jail when we model the game play and not the dice.

Testing Random Behavior

While we have only added two trivial methods for this class, we should test it to make sure it does what we think it should do. The problem is we can't set the values of a Dice object. We made sure of this in the last article. So how do we know if doubles() or even the value() method will work? They look simple enough.

The answer is to use some probability in our test of rolling doubles. If we roll the dice 100 times, I am sure we will get a double, probably more! So let's write the test:

namespace Test\Monopoly;
class DiceTest extends \PHPUnit\Framework\TestCase
  {
  public function testDoublesDice() : void
    {
    $dice = new \Monopoly\Dice();
    $doubleCount = 0;
    for($i = 0; $i < 100; ++$i)
      {
      $dice->roll();
      $values = $dice->values();
      $value = $values[0] + $values[1];
      $this->assertEquals($value, $dice->value());
      if ($dice->doubles())
        {
        $this->assertEquals($values[0], $values[1]);
        ++$doubleCount;
        }
      else
        {
        $this->assertNotEquals($values[0], $values[1]);
        }
      }
    $this->assertGreaterThan(0, $doubleCount);
    }
  }

Notice we are testing each roll for value(). Might as well, as we need to get the values array for the rest of the test. Then, if we have doubles, we check to make sure the values are equal, if it is not a double, then confirm the values are different.

Only one more thing to test, which is, did we get any doubles? So we count the doubles and make sure we have at least one.

Modeling Dice Images

Our standard ADie class does not deal with images of the die, but what if we wanted to show the die to our user? How would we implement this? First, we need to decide how we are going to show the die to the user. We could return a simple image, or we could do it in CSS. There are many 3D dice models out there, but we will try a more simple 2D representation.

We want to get a face of the current value. Let's go to the code:

namespace Monopoly;
class ImageDie extends \ADie
  {
  public function getFace() : \PHPFUI\HTML5Element
    {
    $face = new \PHPFUI\HTML5Element('div');
    $face->addClass('face');
    $value = $this->value();
    while ($value--)
      {
      $face->add('<span class="pip"></span>');
      }
    return $face;
    }
  }

As with any HTML page, we need to add some CSS.

.face {
    display: grid;
    grid-template-areas:
        "a . c"
        "e g f"
        "d . b";
    flex: 0 0 auto;
    margin: 16px;
    padding: 10px;
    width: 104px;
    height: 104px;
    background-color: #e7e7e7;
    box-shadow: inset 0 5px white, inset 0 -5px #bbb, inset 5px 0 #d7d7d7, inset -5px 0 #d7d7d7;
    border-radius: 10%;
}
.pip {
    display: block;
    align-self: center;
    justify-self: center;
    width: 24px;
    height: 24px;
    border-radius: 50%;
    background-color: #333;
    box-shadow: inset 0 3px #111, inset 0 -3px #555;
}
.pip:nth-child(2) {grid-area: b;}
.pip:nth-child(3) {grid-area: c;}
.pip:nth-child(4) {grid-area: d;}
.pip:nth-child(5) {grid-area: e;}
.pip:nth-child(6) {grid-area: f;}
.pip:nth-child(odd):last-child {grid-area: g;}

Now we can write a simple web page that will show a random roll of all six die on each load.

$page = new \PHPFUI\VanillaPage();
// add the above css to the page
$page->addCSS('.face {
    display: grid;
    grid-template-areas:
        "a . c"
        "e g f"
        "d . b";
    flex: 0 0 auto;
    margin: 16px;
    padding: 10px;
    width: 104px;
    height: 104px;
    background-color: #e7e7e7;
    box-shadow: inset 0 5px white, inset 0 -5px #bbb, inset 5px 0 #d7d7d7, inset -5px 0 #d7d7d7;
    border-radius: 10%;
}
.pip {
    display: block;
    align-self: center;
    justify-self: center;
    width: 24px;
    height: 24px;
    border-radius: 50%;
    background-color: #333;
    box-shadow: inset 0 3px #111, inset 0 -3px #555;
}
.pip:nth-child(2) {grid-area: b;}
.pip:nth-child(3) {grid-area: c;}
.pip:nth-child(4) {grid-area: d;}
.pip:nth-child(5) {grid-area: e;}
.pip:nth-child(6) {grid-area: f;}
.pip:nth-child(odd):last-child {grid-area: g;}');

$faces = [];
$imageDie = new ImageDie();
// make sure we have a face for every possible value
while (count($faces) < 6)
    {
    $faces[$imageDie->value()] = $imageDie->getFace();
    $imageDie->roll();
    }
// add to page and display
foreach ($faces as $face)
    {
    $page->add($face);
    }
echo $page;

We now have an ImageDie class that we could make much fancier, but this is a simple example.

How to Test HTML and CSS

While this is another fairly trivial class, we still should test it. But how? The code outputs HTML as a string. How do we know it is valid HTML? We did write a program (above) to see that it worked for our own eyes, but it would be nice to know if a future change invalidates the HTML for some reason. I had this problem before, so I wrote a solution for it! It is called phpfui/html-unit-tester and it uses the W3C Java validation server. Check out the installation instructions if you want to follow along at home.

namespace Tests\Monopoly;

class ImageDieTest extends \PHPFUI\HTMLUnitTester\Extensions
  {
  public function testImageDieFaces() : void
    {
    $page = new \PHPFUI\VanillaPage();
    $page->setPageName('ImageDie Test');
    $css = '.face {
      display: grid;
      grid-template-areas:
          "a . c"
          "e g f"
          "d . b";
      flex: 0 0 auto;
      margin: 16px;
      padding: 10px;
      width: 104px;
      height: 104px;
      background-color: #e7e7e7;
      box-shadow: inset 0 5px white, inset 0 -5px #bbb, inset 5px 0 #d7d7d7, inset -5px 0 #d7d7d7;
      border-radius: 10%;
    }
    .pip {
      display: block;
      align-self: center;
      justify-self: center;
      width: 24px;
      height: 24px;
      border-radius: 50%;
      background-color: #333;
      box-shadow: inset 0 3px #111, inset 0 -3px #555;
    }
    .pip:nth-child(2) {grid-area: b;}
    .pip:nth-child(3) {grid-area: c;}
    .pip:nth-child(4) {grid-area: d;}
    .pip:nth-child(5) {grid-area: e;}
    .pip:nth-child(6) {grid-area: f;}
    .pip:nth-child(odd):last-child {grid-area: g;}';

    $this->assertNotWarningCss($css);
    $this->assertValidCss($css);
    $page->addCSS($css);
    $faces = [];
    $imageDie = new \Monopoly\ImageDie();
    // make sure we have a face for every possible value
    while (\count($faces) < 6)
      {
      $face = (string)$imageDie->getFace();
      $this->assertValidHtml($face);
      $faces[$imageDie->value()] = $face;
      $imageDie->roll();
      }
    // add to page and display
    foreach ($faces as $face)
      {
      $page->add($face);
      }
    $html = (string)$page;
    $this->assertValidHtmlPage($html);
    }
  }

Notice we are testing the CSS to see if it is valid and has no warnings. We also test each face, then the entire page.

Other Examples

We could add a name() method to name specific die, or we could add a color, the possibilities are only limited by your imagination and needs.

What we have done with MonopolyDice is created a concrete class that solves our application's needs. We don't have to worry if someone else can use it. We are not writing a generic library for all PHP users. We could easily do a D&D dice class. In this example, we probably want to get specific groups of die, so we could add more specific methods to organize the dice. The point is, we don't have to worry about rolling or displaying individual dies. The class does that for us at any level we want.

Follow Along At Home

I am posting all the code in this blog to https://github.com/phpfui/ThoughtsBlogCode so you can experiment with the code yourself.

Takeaways

• Inheritance does not have to be complicated. But it should follow ISA relationships.

• Inheritance does not prevent you from using composition. Our Dice class uses composition (contains instances of the ADie class). \Monopoly\Dice uses inheritance.

• You can add additional methods and properties to child classes to make them more specific to your needs. Not everything needs to be in the parent class.

• Don't worry about use cases you will not need, write classes for your needs.

NEXT: - Getters And Setters VS Public Access

PREVIOUS: - PHP Object Oriented Programming

While this article uses PHP for examples, the concepts apply to all languages that correctly implement classes. Some languages don't implement classes correctly (looking at you JavaScript) and should not be used for OO programming.

But OOP is "TOO HARD"!

I think the real problem here is people confuse "inheritance" as the only way to do OO programming. Inheritance is generally the last resort and least used OO feature, or at least it should be. OO Programming is really about the separation of concepts and their implementation. A class can wrap an implementation of a concept and that allows you to change the implementation without affecting the concept, or where it is used. This gives your program more resilience to the inevitable change that happens to useful programs.

A Simple Example

Let's try an OO approach to a problem that does not involve inheritance: a Die!

A die is quite simple. The common die has 6 sides with the numbers (or dots) numbered 1 to 6. One side is always up. But some die can have more or fewer sides, depending on the game. A coin can be used as a die, it has two sides, heads or tails. A four-sided die looks like a pyramid (and in this case, does not have a side that is up, but down!) A twelve-sided die is starting to look like a ball. In our virtual world of die, we are going to assume you can have an odd size die (can you have a physical three-sided die?), but you might want to prevent that in some cases.

A die can also be rolled and has a value. The die sides may not be simply numbered, but have a pattern with a specific meaning. For this example, we will just implement a numbered die. In my next installment, we can use inheritance to implement patterns and more complex die imaging.

ADie Class

So now we have determined the 3 properties of a die:

1. Number of sides

2. Ability to roll

3. Current value

Now time to implement. The first thing we need to do is figure out what is required in our class for it to work. Requirements of a class should be parameters to the constructor, in other words, an object of a die class must be made with the required fields. In our case, we need to know the number of sides a die has, so this becomes a parameter for our constructor.

The ability to roll is a verb. A verb is an excellent name for a class method. Class methods generally ask the class something (often called getters), or modify a class, which is the case for roll. Methods on objects should mostly be thought of as verbs doing or getting something from the object.

Plus we need to get the current value of the die.

And finally, since die is a PHP reserved word, we will have to call our class ADie, which seems to be a nice single-sounding name.

So let's put it all together:

class ADie
  {
  private int $value;
  public function __construct(private readonly int $sides = 6)
    {
    if ($sides < 2)
      {
      throw new \Exception(__CLASS__ . ' must have at least 2 sides');
      }
    $this->roll();
    }
  public function roll() : int
    {
    $this->value = mt_rand(1, $this->sides);
    return $this->value;
    }
  public function value() : int
    {
    return $this->value;
    }
  public function sides() : int
    {
    return $this->sides;
    }
  }

So what have we done here?

First, we require the number of sides. We are using the PHP 8.0 constructor property promotion feature to declare the $sides argument to be a private property of the class. We are also using the readonly attribute from PHP 8.1 for the $sides property. This is because ADie should not mutate itself while it exists. Then we default to the most common die size of 6 to be kind to our users. Next, we roll the die on initialization. This makes sense because a die always has a side facing up, but we don't know what it will be. And we don't want a developer to cheat by specifying an initial value. Notice how we used the roll() method in the constructor to get the actual value of the die. You can and should call other methods in the constructor if they are of use to you. We also test that the number of sides is two or more. This might point out an issue in your code, but is not strictly needed for the class, more like bulletproofing things to avoid potential bugs.

Next up is a simple roll() method. Notice it returns the value it computes as a courtesy to the developer if they want.

Finally, we have two public functions which return properties of the class. Notice the properties themselves are private. This means no child classes can mess with us, but they can get the information about our class if they need it. I added the sides() method because someone might want to know how many sides a particular ADie object has.

And finally, notice we did not inherit from any other class. ADie is a perfect example of a class that encapsulates an implementation (mt_rand, or any other way of picking a random number), does not let the user of a class mess with its internals, but will also allow for inheritance (next installment) if needed. A perfect object!

Let's Test It!

Before we go any further, let's test the ADie class to make sure it works as expected. We will use PHPUnit.

class DieTest extends \PHPUnit\Framework\TestCase
  {
  public function testDefaultADie() : void
    {
    $aDie = new ADie();
    $this->assertIsInt($aDie->sides());
    $this->assertEquals(6, $aDie->sides());
    $this->assertIsInt($aDie->value());
    // make sure we exercise the roll method
    for ($i = 0; $i < 1000; ++$i)
      {
      $this->assertGreaterThan(0, $aDie->value());
      $this->assertLessThanOrEqual(6, $aDie->value());
      $aDie->roll();
      }
    }
  public function testLargeADie() : void
    {
    $sides = 12;
    $aDie = new ADie($sides);
    $this->assertIsInt($aDie->sides());
    $this->assertEquals($sides, $aDie->sides());
    $this->assertIsInt($aDie->value());
    // make sure we exercise the roll method
    for ($i = 0; $i < 1000; ++$i)
      {
      $this->assertGreaterThan(0, $aDie->value());
      $this->assertLessThanOrEqual($sides, $aDie->value());
      $aDie->roll();
      }
    }
  public function testBadADie() : void
    {
    $this->expectException(\Exception::class);
    $aDie = new ADie(1);
    }
  }

Now we have a working ADie class. But what can we do with it? Most uses of a die involve more than one. They are called Dice!

Another Simple Example: Dice

First, what is the concept of dice? What are we trying to model and what interface do we want to present to the user of our dice class? In forming a concept for dice, we want to roll them for sure. But dice is plural for multiple die. How many dice do we need? Monopoly uses only two die, while Yahtzee uses five (if I remember from my youth). So our dice class needs to know how many die to model, and we need to roll them, but we also need to see the result of the roll. So the Dice class sounds like it needs to contain multiple ADie to work. But Dice is not a die. Dice are a collection of die. This is where people tend to go wrong with OO programming. But there is a very simple way of figuring out when to use inheritance or not.

ISA and HASA Relationships

This is the fundamental question to ask when doing OO programming. Are you modeling something that is also something more basic, or does your model just have things?

ISA means "is a", as in an iPhone is a smartphone, as a Pixel 6 is a smartphone. They are both smartphones. They could inherit from a common SmartPhone class. An old-fashioned rotary phone is also a phone, but not a smartphone. But they are all phones, so they could inherit from a Phone base class. I will get more into inheritance in the next installment.

But in our case, dice are clearly not a single die. Dice is the word for multiple die.

HASA is short for "has a", or in the case of dice, has multiple die. So we want Dice to "have" ADie. HASA relationships are called "composition" as opposed to ISA relationships, which are known as "inheritance".

Let's design a Dice class

We need our Dice class to hold multiple ADie. We also need to roll them. And finally, we need to get the values of the rolled ADie objects. We might also want the ADie objects themselves if they represent more than a simple value, for example, they have properties like names, images, etc.

class Dice implements \Countable
  {
  private array $dice = [];
  public function add(ADie $dice = new ADie()) : int
    {
    $this->dice[] = clone $dice;
    return $this->count();
    }
  public function count() : int
    {
    return count($this->dice);
    }
  public function roll() : void
    {
    foreach ($this->dice as $aDie)
      {
      $aDie->roll();
      }
    }
  public function values() : array
    {
    $values = [];
    foreach ($this->dice as $aDie)
      {
      $values[] = $aDie->value();
      }
    return $values;
    }
  public function getDies() : array
    {
    $values = [];
    foreach ($this->dice as $aDie)
      {
      $values[] = clone $aDie;
      }
    return $values;
    }
  }

The first thing to notice about this class is that it has no constructor. Why? Because we can initialize the single property with an empty array. PHP constructors are optional if can initialize the object to a valid state with just property initializers. While Dice with no associated die is probably not useful or a valid use case, our class will work with no Die in it, so we don't need a constructor, the object is valid without one.

The real work starts with the add() method. We pass it an ADie object we want to add. We are using the PHP 8.1 feature that allows a default value to be a new object, in this case, a default six-sided ADie. Our users can add as many ADie as they want and of any type of ADie.

We have also implemented the PHP interface Countable, which means we find out the number of ADie objects contained in our Dice object.

The final three methods perform actions on our Dice. We can roll them, get their values, or copies of the actual ADie objects themselves. This might be useful if we have Dice with more specific properties (which I will go into more detail in the next installment.)

One thing to note is while the ADie and Dice classes both have a roll() method, they are different and not related other than they perform the same function. Some developers might think this is a reason for inheritance, but it is not. In PHP land, you could implement a Roll interface if you needed to pass both Dice and ADie class objects into something that did not care what it was rolling, but that is a more advanced discussion.

You might be asking yourself why does the getDies() method clone the returned ADie objects? Quite simple actually. PHP objects are always passed by reference, meaning the same object is always used even when you "copy" them into an array, or pass them as a parameter to a method. The add() method also clones the ADie object. This means the original ADie the programmer added to the Dice collection can not be changed from the outside by holding on to the ADie object and calling the roll() method on the ADie object. Hmm, seems like we should test this!

Test Those Dice!

class DiceTest extends \PHPUnit\Framework\TestCase
  {
  public function testDefaultDice() : void
    {
    $dice = new Dice();
    $this->assertCount(0, $dice);
    $dice->add();
    $this->assertCount(1, $dice);
    $dice->add();
    $this->assertCount(2, $dice);
    $dice->add();
    $this->assertCount(3, $dice);
    $dice->add();
    $this->assertCount(4, $dice);
    $dice->add();
    $this->assertCount(5, $dice);
    $dice->roll();
    $values = $dice->values();
    $this->assertCount(5, $values);
    $dies = $dice->getDies();
    $this->assertCount(5, $dies);
    for($i = 0; $i < 5; ++$i)
      {
      $this->assertEquals($values[$i], $dies[$i]->value());
      }
    }
public function testCustomDice() : void
  {
  $dice = new Dice();
  $this->assertCount(0, $dice);
  $sixDie = new ADie(6);
  $dice->add($sixDie);
  $this->assertCount(1, $dice);
  $eightDie = new ADie(8);
  $dice->add($eightDie);
  $this->assertCount(2, $dice);
  $twelveDie = new ADie(12);
  $dice->add($twelveDie);
  $this->assertCount(3, $dice);
  $sixteenDie = new ADie(16);
  $dice->add($sixteenDie);
  $this->assertCount(4, $dice);
  $eightteenDie = new ADie(18);
  $dice->add($eightteenDie);
  $this->assertCount(5, $dice);
  $dice->roll();
  $values = $dice->values();
  $this->assertCount(5, $values);
  $dies = $dice->getDies();
  $this->assertCount(5, $dies);
  $sideCount = [6, 8, 12, 16, 18];
  for($i = 0; $i < 5; ++$i)
    {
    $this->assertEquals($values[$i], $dies[$i]->value());
    $this->assertEquals($sideCount[$i], $dies[$i]->sides());
    }
  // roll our copies of the dies, then test to see if things have changed with the Dice copy
  $sixDie->roll();
  $eightDie->roll();
  $twelveDie->roll();
  $sixteenDie->roll();
  $eightteenDie->roll();
  $newValues = $dice->values();
  $this->assertCount(5, $newValues);
  $newDies = $dice->getDies();
  $this->assertCount(5, $newDies);
  for($i = 0; $i < 5; ++$i)
    {
    $this->assertEquals($values[$i], $newValues[$i]);
    $this->assertEquals($newDies[$i]->value(), $dies[$i]->value());
    $newDies[$i]->roll();    // roll and see if we can affect next test
    }
  $newValues = $dice->values();
  $this->assertCount(5, $newValues);
  $newDies = $dice->getDies();
  $this->assertCount(5, $newDies);
  for($i = 0; $i < 5; ++$i)
    {
    $this->assertEquals($values[$i], $newValues[$i]);
    $this->assertEquals($newDies[$i]->value(), $dies[$i]->value());
    }
  }
}

I will leave it to the reader to fully understand the tests for the Dice class, but look for the following:

• Default add() parameter

• count functionality

• Invariance of the Dice class even if the ADie objects that are added to it change

Fool around with the code and see what happens when you remove the clones from the add() and getDies() methods.

Follow Along At Home

I am posting all the code in this blog to https://github.com/phpfui/ThoughtsBlogCode so you can experiment with the code yourself.

Takeaways

Here is what I hope readers understand from the above:

• Object Oriented programming does not always mean inheritance.

• Objects allow you to hide your implementation. You can change how you do things without affecting your users, like a better random function.

• Always think about ISA or HASA before you start designing and writing code.

• Always write tests to confirm your objects work as expected.

Next Time

We are going to talk about inheritance in the next installment. We can extend both the ADie and Dice classes to be more specific for specific use cases.

NEXT: - PHP Inheritance Explained

PREVIOUS: - PHP 8.2 Release Day

You don't have to wait till a new version of PHP is officially released. You can find prerelease versions on php.net if you look around, but things are easier if it has been officially released.

Upgrading to PHP 8.2

Don't use any new PHP 8.2 features just yet!

While we might all be eager to start using the latest PHP features, there is a lot of work to do before you can start using readonly classes!

Upgrade your local machine first

With any new PHP version, you should make sure your code works with it locally before you think about using it anywhere else.

Confirm your installation is correct

Type php -v at a command line (assuming it is pathed correctly) and it should return something like:

PHP 8.2.0 (cli) (built: Dec 6 2022 15:31:23) (ZTS Visual C++ 2019 x64) Copyright (c) The PHP Group Zend Engine v4.2.0, Copyright (c) Zend Technologies with Zend OPcache v8.2.0, Copyright (c), by Zend Technologies with Xdebug v3.2.0RC1, Copyright (c) 2002-2022, by Derick Rethans

The next step is to confirm your webserver is seeing PHP 8.2. Add a test.php script to your server root:

<?php
phpinfo();

Browse to your localhost/test.php and confirm it says PHP 8.2. Then delete it.

Make sure error_reporting is set to E_ALL

Local development machines should have error_reporting = E_ALL in php.ini. This will show all potential problems in your code such as new depreciations in 8.2

Update composer

This is a critical step. You may need updated packages for PHP 8.2.

Run unit tests!

This is a prime reason for unit tests. Fix any errors that come up. The most common will be dynamic properties in classes. The PHP team has plugged this hole that most scripting languages allow. You now must declare all properties a class uses or you will get a depreciation warning. This is a great feature, as it helps detect typos and refactoring issues.

Exercise your site

While your unit tests should cover all use cases, they rarely do. Try to hit as many different types of pages as possible on your local machine. Don't forget about cron jobs or API interfaces that are not user-facing.

Update any packages you maintain

If you are a package maintainer and have not already made sure your package is compatible with PHP 8.2, now is the time to upgrade. I recently found I had to update versions of GitHub actions to avoid depreciated configurations. Make sure you are testing PHP 8.2. And now is the time to reconsider support for older versions. A good rule of thumb is to only support "supported" versions of PHP. I also will drop older versions if they cause any grief with unit tests, package support, or even automated code formatting conflicts.

Submit PRs for any packages you use that are not PHP 8.2 compatible

Often with more mature packages, new versions of PHP can cause issues. While major packages are often updated to the latest version of PHP before it is released, not all packages are updated regularly, even if they are widely used and actively supported.

Be kind and submit a PR. If you can't figure out how to fix an issue, at least open an Issue explaining the to maintainer what the problem is. Often it is just an oversight.

Get the rest of the team on 8.2

It makes sense to have just one person update to a new version of PHP to test the waters. Once you have confirmed your local machine runs with PHP 8.2, you will want to get the rest of the team up on 8.2. I generally document machine setups from scratch, as it helps onboard new developers. The same applies to PHP upgrades.

Update your CI pipeline

Make sure your CI pipeline supports the new version of PHP. You can probably now also stop supporting the previous old version of PHP you were using before the last time you updated the pipeline. Your pipeline only needs to support the current production version and the upcoming version.

Update the development server to PHP 8.2

The development server often sees more use than your local machine, so time to get it up and running PHP 8.2. Your error reporting pipeline should warn you of any issues. Again, error_reporting should be set to E_ALL in php.ini to help find issues.

Update QA and staging servers after the current release cycle

At this point, you should be fairly confident your PHP code is capable of running under 8.2 and you need to start pushing 8.2 to more environments and users, but not to production just yet.

Decide when to go live with PHP 8.2

OK, this is the big hard step most management types hate, upgrading something that "works". I generally watch the PHP updates and see what kind of issues are exclusive to the new PHP version. It generally turns out that most issues in a new release of PHP are in older versions as well. I good rule of thumb is to wait for 2-3 releases before deploying to production.

If you still get pushback from the higher ups, just remind them that Ford Model Ts still "work" but no one uses them as a daily driver. Upgrading to modern infrastructure is always time well spent. The last thing you want to happen is being 4-5 versions behind when a major security issue is found. Not fun. Upgrading regularly (every year in the case of PHP) is the right approach. Not too many changes at one time, but often enough you don't get left behind.

Wait one release cycle for PHP 8.2 features

Once you have PHP 8.2 in production, you should wait one release cycle to start using new PHP features. This way you can back out if a disaster hits.

Enjoy PHP 8.2!

And now you are all set to do it again next year. Once you have done the process all the way through, you are ready for the next time!

NEXT: - PHP Object Oriented Programming

PREVIOUS: - Packagist Best Practices

Don't check in composer.lock

While you want to check in your lock file for testing and release for your own website, lock files DO NOT belong in a package. If you need a specific version of another package, specify the version in the require section. Composer will handle the rest.

Run "composer outdated" regularly to make sure you are not requiring older versions of other packages.

require-dev

    "require-dev": {
        "phpunit/phpunit": ">=8",
        "roave/security-advisories": "dev-latest",
        "friendsofphp/php-cs-fixer": ">=3.0",
        "phpstan/phpstan": "^1.8"
    }

Make sure you do not include test packages or anything else required only for development in the require section, or these packages will be hauled into production. Not good!

PSR-0 or PSR-4 autoloading only

    "autoload": {
        "psr-4": {"PHPFUI\\": "src/PHPFUI/"}
    },
    "autoload-dev": {
        "psr-4": {"Fixtures\\": "tests/Fixtures/"}
    }

It is 2022 already, and you should let Composer handle things for you. There is absolutely no reason to include autoloader.php files or any other file that includes another file to make your package run correctly. You should have NO includes in any source file. This just adds complexity to something Composer handles automatically.

Use PSR-0 or PSR-4 autoloading exclusively. Both work great and will allow proper autoloading. DO NOT use functions, global or otherwise, as these break faster autoloading since they can not be easily loaded as compared to classes. Instead, use static methods in a class. This will autoload correctly and is the same thing as a standalone function. Global functions are bad practice and namespaced functions are just annoying for autoloading and not needed.

Use autoload-dev for PSR autoloading of your tests. Do not list your test files in the normal autoload section, as this will cause your tests to deploy to your user's production.

Put all source files in the src directory

The src directory should only include the source files that you want in production. DO NOT include test or example code here. Any files that are not PHP source code, but required for operation, should be included here and referenced in the source code with the __DIR__ PHP macro.

With PSR-0 loading you will have to start from the root namespace in the src directory. PSR-4 allows you to skip deep namespace directories, but which you use is an individual preference.

Put all tests in the test directory

I tend to name the directory Test to indicate it is in Test namespace, which makes autoloading a bit easier and clearer. Any files needed for testing can be placed in the test directory.

Put examples in an examples directory

Feel free to add subdirectories to the examples directory, but examples should not be in the project root.

Proper PHP versioning

    "require": {
        "php": ">=7.4 <8.2"
    },

Make sure you specify your PHP version correctly. You want to specify a minimum version at a minimum. I personally also specify a maximum version, then update packages when a new version of PHP ships. For example, >=7.4 <8.2 is very clear as to what versions of PHP the package supports and prevents subtle issues in the new PHP version from affecting production before the package is fully supported. If you are not going to maintain the package, publish a version without limiting the maximum PHP version to be kind to others.

GitHub actions

GitHub actions are an excellent way to test your package. Actions can test various configurations of PHP and OSes easily. Here is a nice example of an action testing PHP 7.4 - 8.1 under Windows and Linux:

name: Tests

on: [push, pull_request]

jobs:
  php-tests:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: true
      matrix:
        php: [8.1, 8.0, 7.4]
        dependency-version: [prefer-lowest, prefer-stable]
        os: [ubuntu-latest, windows-latest]

    name: ${{ matrix.os }} - PHP${{ matrix.php }} - ${{ matrix.dependency-version }}

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}
          extensions: dom, curl, libxml, mbstring, zip, bcmath, intl
          coverage: none

      - name: Install dependencies
        run: |
          composer install --no-interaction
          composer update --${{ matrix.dependency-version }} --prefer-dist --no-interaction --no-suggest

      - name: Execute tests
        run: vendor/bin/phpunit

Code standards

You should have code standards. I find PHPStan does a good job of linting PHP code. Level 6 is a reasonable level to strive for. Go for more if you like.

PHPCSFixer is another great tool for formatting code. I run it on git check-in to keep things neat. It has a great configuration tool here. Highly recommended.

Check any config files from these tools into the root of your project. This will allow contributors to run the same tests and checks you use.

Have a Good README.MD

Your README.MD file is your primary sales tool. It should have the following sections:

• Overview

• Installation if other than composer require

• Explain the features of your package

• Examples

• Documentation or links to documentation

• Other interesting links

• License

Assume your users know how to install packages, get to your GitHub repo, and understand dependencies, as Packagist handles all this for you.

Badges

Badges are a great thing to add to a README.MD, while they don't show up on Packagist, they do on GitHub and can give users a better idea of what the package supports. Here are some example badges:

[![Tests](https://github.com/phpfui/phpfui/actions/workflows/tests.yml/badge.svg)](https://github.com/phpfui/phpfui/actions?query=workflow%3Atests)

[![Latest Packagist release](https://img.shields.io/packagist/v/phpfui/phpfui.svg)](https://packagist.org/packages/phpfui/phpfui)

![](https://img.shields.io/badge/PHPStan-level%206-brightgreen.svg?style=flat)

License and other status files

Make sure you include a license file and add the license to the composer.json file. This helps document your intent and adding it to composer.json makes it super easy for license reporting for your users.

Try this command just for fun: composer license

Other files you may want to include are codes of conduct, code style (if not automated with PHPCSFixer), Pull Request guidelines and other administrative files that are not directly related to the code. These files should be at the root of the project for easy viewing.

Full docs

One of the sore points of Open Source is the lack of documentation. Any docs for the code, and not the above administrative files, should be in a docs directory. This will direct developers to the important files. Use file names that describe what the documentation is about. You can also number them to show them in a specific order. All of this helps others and bots to find your documentation and present it to developers.

Automated docs are even better! I wrote InstaDoc for exactly this reason. There is no reason not to fully document your PHP code and display the docs if you can host a website someplace.

.gitignore

.bash_history
.idea/
.php-cs-fixer.cache
.phpintel
.viminfo
.DS_Store
phpunit.html
psalmCommitErrors.txt
tmp/
/vendor/

Make sure your .gitignore file is up to date! You should be able to run all tests, code cleanup, linting or other automated tools and not leave unstaged files in git. You should also exclude any files your editor or operating system includes (looking at you .DS_Store)

Often new versions of dev tools create new cache file names, so check periodically to make sure things are not missed.

NEXT: - PHP 8.2 Release Day

PREVIOUS: -Benchmarking PHP Autoloaders

Autoloading is not FREE!

Like everything else, autoloading is not free. There are runtime and memory costs for most autoloaders. Try this code in your project:

$startMemory = memory_get_usage();
$startTime = microtime(true);

include 'vendor/autoload.php';

$endTime = microtime(true);
$finalMemory = memory_get_usage();

\(memoryUsed = \)finalMemory - $startMemory;
\(microSeconds = \)endTime - $startTime;

echo "Composer autoload takes {$memoryUsed} bytes of memory\n";
echo "and took {$microSeconds} to load\n";

All this code does is load the autoloader. Nothing else.

For my documentation website PHPFUI, here are the results from my Windows machine, which is an Intel Core i7-8550U CPU @ 1.80GHz running PHP 8.1:

Composer autoload takes 752464 bytes of memory
and took 0.010792970657349 to load

Autoloader Memory Costs

As you can see, the default Composer autoloader is using 752K of memory every time. This number never changes for my benchmark as the autoloader is doing the same thing every time (runtimes can vary based on Windows timing).

That is A LOT of memory just to autoload classes. Think about the number of PHP processes you have running on a server. Each one now loads an additional 752K of memory. Not great.

Autoloader Runtime Costs

Runtimes are harder to benchmark, as it depends on the underlying OS (Windows 11 in my case), and system load among other things. But multiple runs of this program on my machine show time ranges from 0.0102119 to 0.0107929 with no other loads on the system. While this may not seem like a lot of time, it does add up. One hundred requests to your server have just burned up 1 second of CPU time. How many requests a day are you getting? Benchmark your production machine and do the math.

So what to do?

Use The World's Fastest Autoloader!

One of the best things about PHP is the namespace design. PHP namespaces look exactly like a file path in the OS. We can leverage that for our world's fastest autoloader (WFA). If you are using best practices for minimizing supply chain attacks (you ARE doing this, right?), then you have already done most of the work for the WFA.

In this example, I have put all Composer / Packagist sourced code into the project root and placed this autoload in the project root. You can find a detailed explanation of how this code works here.

define ('PROJECT_ROOT', __DIR__);
spl_autoload_register(function ($className)
{
    \(path = PROJECT_ROOT . '\\' . "{\)className}.php";
    \(path = str_replace('\\', DIRECTORY_SEPARATOR, \)path);
    if (file_exists($path))
        include_once $path;
});

Now let's rerun our benchmarks with this code:

$startMemory = memory_get_usage();
$startTime = microtime(true);

define ('PROJECT_ROOT', __DIR__);
spl_autoload_register(function ($className)
{
    \(path = PROJECT_ROOT . '\\' . "{\)className}.php";
    \(path = str_replace('\\', DIRECTORY_SEPARATOR, \)path);
    if (file_exists($path))
        include_once $path;
});

$endTime = microtime(true);
$finalMemory = memory_get_usage();

\(memoryUsed = \)finalMemory - $startMemory;
\(microSeconds = \)endTime - $startTime;

echo "WFA autoloader takes {$memoryUsed} bytes of memory\n";
echo "and took {$microSeconds} to load\n";

WOW! That was FAST

WFA autoloader takes 816 bytes of memory
and took 1.8119812011719E-5 to load

As you can see, we reduced almost all the memory usage and got the runtime down to 0.00000181198 seconds. That is pretty impressive!

Now let's try loading some classes

I happen to have 182 classes I can easily autoload with no constructors. I reset the time and memory variables, did a new on each class, then recomputed the time (not worried about memory here, it is what it is for the classes). Your test results will be different from mine depending on what you are loading. My classes do not access the database or any other resources.

Here are my results:

Composer autogenerated autoloader took between 0.049884080886841 and 0.057215929031372 seconds to load.

The world's fastest autoloader took between 0.0505051612854 and 0.056947231292725 seconds to load.

They are close enough to not make that much of a difference at run time. The file loading and PHP initialization are the same for each method. This makes sense, as the Composer autoloader is doing a mapped array lookup and then loading the file. The WFA does some minor string manipulation and then loads the file.

The problems with the Composer autoloader

Besides having a large memory footprint, the Composer autoloader does not have a Big O runtime of 1, like the WFA, but rather log N, which is small, but not 1. As your app grows, the autoloader slows down and consumes even more memory. It is all downhill from the first composer install!

Conclusion: WFA for the Win!

The Composer generated autoloader has a high cost you're paying for on every PHP page served. Reduce your costs by using the world's fastest autoloader!

NEXT: - Packagist Best Practices

PREVIOUS: - Why Use PHP In 2023

Fully Open Source

First, it is 100% open source. I don't have to worry about licensing, or being mostly maintained by evil company X. It has an open process for adding new features to the language and a predictable release schedule.

Easy to Upgrade

It has been easy to upgrade from previous versions of the language to the latest release. You can't say that about Python, Perl or several other languages. Often a new version of the language impacts older users preventing them from upgrading to more modern features. Each of my PHP upgrades from 4.2 to 8.1 (and soon to be 8.2) has been relatively painless. Tools such as Rector make it even easier to move between versions with both up and down grade paths.

Great Documentation

You can say whatever you want about PHP, but the documentation for the language is some of the best I have ever seen, including classic IBM documentation from back in the heydays of PL/1. Contrast that to what passes for documentation from other companies with a paid staff, and you can appreciate the quality of the documentation.

Great User Community

One of the features of the PHP documentation is user comments. These are curated and often explain subtle things that may not be covered in the official docs. Users often contribute source code to help solve a specific problem, or offer tips they found while trying to get something to work. These insights are particularly helpful when trying a new feature or function.

The user community also extends to Stack Overflow and other developer help sites. In other languages I have used, the breadth of the user community is much smaller and often it is hard to find the solution to your problem. With PHP, it is really easy to find a solution to any problem you have.

Huge Selection of Open Source Packages

Packagist.org is a great resource for finding PHP packages to solve your problem.

Amazing Dependency Management

I have used several dependency managers in other languages and I find Composer is the best in class. Other dependency managers are slow, not easily configurable, or just plain have bugs and/or lack features that are in Composer.

Well Matched To Web Development

PHP stands for PHP Hypertext Processor, and that is exactly what it is. The PHP language processes things into hypertext. I would not use PHP for much beyond the web and other text-based things, like command line programs, but it is ideally suited to processing text, and the web is text-based.

And since PHP started as a web-based language, it has all the supporting functions you would expect in a web-based environment.

Easy to Learn

PHP is extremely easy to use. Even novice developers can be quickly productive writing basic PHP code to produce a website. This is also PHP's Achillies Heal, it is so easy to write code, you often get newbie developers with no architectural skill writing bad code. But it is also easy and a pleasure to write great object-oriented PHP code.

Easy to Deploy

My deployment cycle consists of doing a git pull, deleting a few files and running any new migrations. Super fast, simple and reliable. Compare that to the horror stories you hear about other language website deployments.

Fast Deploy / Test Cycle

Unlike compiled language, PHP is interpreted at runtime. While this may be a problem for high-volume sites, it means as soon as you save your PHP files to disk, you can test your site. Compare this to a compiled or transpiled language and you have a delay (and at least one other step) before you can test. While it may not seem like a big deal to wait, this can seriously degrade your ability to make fast changes to your CSS, HTML and even logic, as you polish your site.

Widely Supported Hosting

Every hosting service will offer PHP support. Not true for just about any other language. Often you have to deploy the language yourself if you can get it to work at all. Just running a JVM can be problematic unless your hosting service specifically supports it.

Good Object Model

While not perfect, PHP has a decent object model you can use for object-oriented development. It lacks a few things like operator overloading so you can't truly add new scalar-like types to the language. But it handles most OO use cases quite well.

Supports Procedural and Functional Style Development

If you have never figured out the OO style, you can still do the older Procedural and Functional styles of programming. PHP supports both very well. And PHP does not force you into any particular style. You can mix and match.

Multi-Platform

PHP runs equally well on Linux, OSX or Windows operating systems. And since it is written in C, it can be easily ported to any future OS or computer architecture fairly easily if needed. So I can develop on Windows with a great UI experience and deploy on Linux. The only issue tends to be both Windows and OSX are not case sensitive, whereas Linux is, so you can get into autoloading issues if your file case does not match.

PHP Is FAST!

For an interpreted language, PHP is at the top of the pile. The fastest PHP combo tested came in at position 31. All faster tests are from compiled languages. Python first shows up at position 236. With just one anomaly, JavaScript comes in at position 128. Ruby does not show up till 280.

While you can cherry-pick benchmarks, PHP does quite well for any combination and is an indication of the speed of PHP in general. Add speed of development and deployment, and PHP looks like a solid choice.

Full Reflection

Since PHP is a scripting language, and you can effectively create PHP on the fly, Reflection classes come in really handy to check out classes and objects at runtime. Reflection classes allow your code to inspect any class or object at run time and pull out the entire class or object definition, including access to protected and private members. I used this functionality to create fully hyperlinked PHP class documentation on the fly for any autoloadable PHP class. Check out PHPFUI for a live demonstration.

Finally, it is just FUN to write in PHP

And that is the main reason I still write PHP in 2022. Because if it is not fun, why bother?

NEXT: - Benchmarking PHP Autoloaders

PREVIOUS: - PHP Error Logging To Slack