PHP Modern Practices Latest Evolution Steps

Contents

Important Well Known Modern PHP Practices

PHP 7 Only Packages

Help Your Class Users Benefit of Strict Typing when They Want

Extreme Code Reuse with Traits

Less Obvious Modern PHP Practices

PHP Packages Implementing PSR Interfaces

Pushing Git to the Point there is No Excuse for not Using Version Control

What about those old bad quality packages, where have they gone?

A Modernized Look

PHP Package Modernization Beyond the Obvious using Data Mining and Business Intelligence

Important Well Known Modern PHP Practices

PHP 7 Only Packages

As you should know by now, the greatest event of last year was the launch of PHP 7. One of the most important features is the possibility to enable strict typing, scalar type hinting for function arguments and return values.

Despite the importance of this event and the excitement among the PHP community, many developers are still being cautious to migrate to PHP 7 because of the maintenance work that it may require to handle backwards incompatible changes that affect their applications developed in the past.

Nevertheless, we are already seeing many PHP 7 only packages being submitted to PHP Classes and other repositories. Therefore, some time ago it was created a new category for PHP 7 only of packages in PHP Classes.

Help Your Class Users Benefit of Strict Typing when They Want

One curious fact about many PHP 7 only classes is that, despite they even use scalar type hinting for function arguments and return values, many classes are not enabling strict typing.

Strict typing allows you to catch bugs that may cause your code to pass values of the wrong types. If strict typing is not enabled by adding declare(strict_types=1); statement at the top of each PHP class source code file, it will still not be enabled even if the calling script file also has declare(strict_types=1);, which is also a required condition.

So the tip for those developers that are not aware of this detail, always add declare(strict_types=1); at the top of all your class files. If the users of your classes do not want to benefit from strict typing, they just need to not add that statement in their calling scripts.

Extreme Code Reuse with Traits

Even before PHP 7 there was an interesting feature that over time is showing more and more adoption. That is the case of traits. Traits allow a different kind of reuse provided by traditional Object Oriented Languages.

Traits avoid the need to do copy and pasting of parts of code that may be reused in many classes, despite traits code does not form a class just by itself. Traits can be used to add common functionality to classes for unrelated purposes.

Last year there was even one article by Dave Smith that explained how to apply traits in practice in your PHP developers. Part 1 and part 2 of the article were published in this site.

Despite traits were added to PHP 5.4, it took a while for the PHP community to start enjoying and producing reusable code based on traits. Nowadays the Traits category of PHP Classes has over 30 of them and a few more in the moderation queue.

Less Obvious Modern PHP Practices

PHP Packages Implementing PSR Interfaces

As you many know, PSR is a standards recommendation defined by the FIG: PHP Framework Interoperabilty Group.

Despite it was launched in 2009, during the first years, the efforts were more focused on defining specifications for coding styles and auto-loading conventions. That is understandable because getting many people to agree on common conventions is hard.

Only more recently several proponents started focusing more on defining specifications for interfaces for classes that implement common functionality useful for many applications like caching, logging, dependency injection containers, event handling among several others that were already accepted or are still being drafted or revised.

Defining proposals for standard interfaces is very useful for all developers. For instance if you create an application that uses a package that implements standard interfaces, if the package developer does not continue to maintain the package for some reason, you may quickly switch to another package that implements the same standard interface with little or no change to your application code.

This is great but the community of package developers as whole needs to embrace the concept. The good news is that it seems to start happening this year in a more noticeable way.

Despite some interface PSRs are still being drafted, there are already several developers providing packages that implement those interfaces.

In the latest months several packages that implement interface PSRs were submitted to the PHP Classes site. Therefore a new category was created to help developers to easily find packages that implement PSR interfaces.

For now they are not many, but since they are new, practically all of them were considered innovative.

We need more interface PSRs and developers that implement compliant packages that implement those interfaces.

To inspire you here is the list of the current PSR interface packages available on the site. Notice that some of these packages are implemented as traits, so it is easy to integrate them in other classes.

CakePHP 2.x Container by Nerijus - Implements PSR 11 Dependency Injection Container interface, so CakePHP applications can be used together with services of other frameworks.

ITE Event Manager by Kiril Savchev - Implements PSR 14 Event publish and subscribe interfaces to register event handlers and trigger events.

ITE Logger by  Kiril Savchev - Implements PSR 3 Logger interface to log messages to different destinations.

ITE PSR-6 Cache by  Kiril Savchev - Implements PSR 6 Caching interface to cache data in different types of storage.

PHP Cache Manager Wrapper by Sergii Pryz - Uses classes that implement PSR 6 caching interface to optimize the caching of dynamically generated data.

Pushing Git to the Point there is No Excuse for not Using Version Control

Despite PHP Classes supports importing packages from version control repositories from Git, SubVersion or CVS systems since 2011, many less experience developers are still not using Git or any other form of version control system.

Some are still willing to upload individual files or zip archives manually. Uploading individual files is still supported but for packages with many files only importing from version control repositories is supported.

By far, GitHub is the most popular repository site that many developers use to manage their package developments.

In case you never submitted a package to PHP Classes imported from GitHub, you may wonder why developers publish packages in GitHub and then import them in PHP Classes or other repositories.

The reason is simple, just dropping your work in GitHub is not enough to make it visible to the community that may want to use it. You need to do the marketing to have your package known among many other users.

That is the main role of PHP Classes since its beginning in 1999. Once you import a PHP package in PHP Classes, not only the site notifies thousands of users by email about your package, but it also gives it additional exposure if you package is considered Notable, or even Innovative.

In the latter case you can even earn recognition and prizes from many PHP sponsors if you share innovative work. Not to mention the holy elePHPant personalized with your name that many developers are eager to get.

To make it easier, now you can just paste the link of a package repository in GitHub and the site will do the rest of the package publication automatically in a single step.

So if before there was the excuse of importing packages in multiple steps, now there is no excuse for not doing it. Just make sure you share great package to enjoy the exposure and recognition you may get.

What about those old bad quality packages, where have they gone?

Once in a while I hear from some developers complaining about bad quality or unmaintained packages. This is a problem with every repository that is open for public contributions.

If there is bad quality or unmaintained code, that is not PHP Classes fault. That is a reflex of the PHP community that we have. We have great smart PHP developers and at the same time there are less experienced developers everywhere.

So if you want to give more visibility to the great quality code, or at least code that is still being maintained, the solution is not to ban or scream at the face of developers that are not as good as we hoped.

The solution is to give more visibility and priority to code that is more recent and hopefully being maintained. So, since a few weeks ago, when you search for packages in the PHP Classes site, there is a factor in the sorting of the results that considers the date of the last package files update.

Just take a look at the search results page for packages and you can see the date of the last update.

It may not be a perfect solution. Recently updated code may not necessarily be of good quality. But at least is a sign that the author has been working on it recently. So it probably is more compliant with more recent PHP versions and takes advantages of their newest features.

A Modernized Look

Finally, if you have not visited the PHP Classes site recently, you may notice that the site has a new modernized design. The site has been through many functionality and design improvements over the years, but there was not a recent redesign of the site looks.

So now it is being launched a new modernized design that uses a flat user interface to follow the latest trends of site looks.

The current redesign still needs a few fixes but this is mostly ready. If you find any issues, please comment here or send a message to info at phpclasses.org to report any issues or make any suggestions of things that you feel need more improvement.

PHP Package Modernization Beyond the Obvious using Data Mining and Business Intelligence

We are in the 21st century. Now computers can process large amounts of data to find relevant information and very low costs.

As a PHP package developer that wants to develop great packages that address the real needs of your users so it attracts many of them, imagine if it was possible to tell what features your packages are missing, the users are looking for them, and the site could tell you what are those features without asking the users!

Or imagine if it was possible to discover what features your users want to use in your package but they don't use because it misses important tutorials or documentation!

Wouldn't that be great? So hang on. That is something that is coming to PHP Classes, hopefully very soon.

For now, if you are a package developer that is interested to use of this upcoming possibility, just mail me at info at phpclasses.org so you can participate in the beta testing of this feature.

The future is arriving now. Lets meet there soon.