Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Exakat Blog:
5 usages of static keyword in PHP
Jun 20, 2018 @ 10:28:21

On the Exakat blog there's a new post sharing five uses of the "static" keyword in PHP applications. This includes the less common static closures and static class names.

Static is a PHP keyword with many usages. It is almost universally used, though there are many variations of it. Let’s review all the five of them :
  • static method
  • static property
  • static closure
  • static variable
  • static as a classname

The post goes through each of the items in the list giving a brief explanation of how it's used and a code example showing it in action. The post finishes with some tips on evaluating your own code for the use of "static" and tips for each to make your code easier to wrangle and maintain in the future.

tagged: static keyword example tutorial method property closure variable classname

Link: https://www.exakat.io/5-usages-of-static-keyword-in-php/

Understanding Design Patterns - Template Method
May 15, 2018 @ 13:07:06

The StarTutorial.com site has continued their series covering common design patterns and their implementation in PHP. In their latest article they cover the Template Method pattern.

[This pattern] defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

In their example, they have two workers that have different schedules but with one difference. Instead of having implementations that differ widely between the two workers (represented by classes) they refactor the main class and allow for a doWork method to be defined in the child. This makes the parent class a sort of "template" for handling the processing with the child filling in the blanks.

tagged: designpattern tutorial template method series

Link: https://www.startutorial.com/articles/view/understanding-design-patterns-template-method

Zend Framework Blog:
PHP 7.2 Support!
May 09, 2018 @ 09:51:55

Matthew Weier O'Phinney has made a post on the Zend Framework blog about the release of PHP 7.2 support for Zend Expressive, now in version 3.

With Expressive 3 complete, we were able to turn our sights on another important initiative: PHP 7.2 support across all components and Apigilty modules.

The short story is: as of today, that initiative is complete! If you are using the Zend Framework MVC framework, Expressive, or Apigility, or any of the ZF components standalone, you should be able to perform a composer update to get versions that support PHP 7.2.

The full story is much longer.

He starts with a look at the path to get to PHP 7.2 support including the considerations for not breaking backwards compatibility as much as possible. He then moves on to the approach they took with changes to the Composer and Travis-CI configuration changes to make it easier to run the tests on multiple PHP versions (with multiple PHPUnit versions too). The post ends with a look ahead at four things coming soon including a PSR-7-based zend-mvc v4, work on the documentation and more tutorials/guides to help devs make the most of Zend Expressive.

tagged: zendexpressive zendframework php72 support path method framework

Link: https://framework.zend.com/blog/2018-05-08-php-7.2-support.html

Exakat Blog:
How many parameters is too many?
May 01, 2018 @ 11:55:47

In a new post to the Exakat blog they try to answer the question "how many parameters is too many" when it comes to the structure of the methods and functions in your application.

Now, that is a classic question, that is often a minefield for anyone writing an increasing long list of argument in a method, or simply trying to set up auditing tools.

Obviously, the answer is not immediate. Parameters may be needed, but on the other hands, currying functions allows to reduce the amount of parameter to one for every function. In between, probably exists a reasonable level that is a golden rule, and also very elusive. So, we decided to check the current practice in PHP code.

They started the research with some of PHP's own native functions that took in specific arguments, ignoring those that took an arbitrary number. Next they made a survey of 1900 open source projects to determine the common practice for parameters by function. The results showed that methods without at least one parameter were "less useful" and that a seemingly reasonable amount of parameters is 5. The post finishes with a spotlight of two they found during their research that had the most parameters: a generated class for database interaction and a dependency injection class.

tagged: parameters count statistics userland native function method results

Link: https://www.exakat.io/how-many-parameters-is-too-many/

Matthias Noback:
Combing legacy code string by string
Apr 18, 2018 @ 09:15:59

In a new post to his site Matthias Noback takes a look at legacy applications and two things that most of them seem to have in common: classes that are too large and too generic methods. In this post he discusses these two topics and some of the tactics you can use to help refactor and resolve them.

I find it very curious that legacy (PHP) code often has the following characteristics:
  • Classes with the name of a central domain concept have grown too large.
  • Methods in these classes have become very generic.

He starts by tackling the "classes too large" problem, suggesting that it's usually just a matter of developers slowly adding to existing functionality rather than introducing large chunks of code all at once. Moving on to the "generic methods" issue, he lays out a common scenario showing how a method evolves over time to repurpose it for other uses thank its original intent. He recommends "taking a step back" and picking apart the code to make the functionality more specific in the places it's used.

tagged: legacy application generic method large class tutorial

Link: https://matthiasnoback.nl/2018/04/combing-legacy-code-string-by-string/

Sarfraz Ahmed:
Laravel: Automatic Vendor Cleanup Command
Jan 25, 2018 @ 09:42:47

In a post to his site Sarfraz Ahmed shares a command that can be used in a Laravel application (via artisan) to clean up unnecessary files from packages that you may have installed.

When installing composer packages, they come up with lot of useless files and folders such as .git, tests, readme.md and more. When project becomes bigger with many packages, this junk takes considerable disk space. Since I work with Laravel framework most of the time, I created a command that allows me to automatically delete all these junk files whenever I happen to install or update composer packages.

He lists out the patterns the command matches by default including "tests", "readme*" and "*.log". There's a long list of items and, having worked with several packages, I can tell you that most of the files caught by this need to be removed anyway. He has posted the code on GitHub and provides some examples of the command line calls and how it can be called automatically.

Another package that does something similar but allows the package itself to define the files to remove is the composerclean library that is executed as a Composer command rather than an artisan command.

tagged: composer laravel automatic clean method artisan

Link: http://codeinphp.github.io/post/laravel-automatic-vendor-cleanup-command/

Laravel News:
New Blade Directives Coming to Laravel 5.6
Dec 13, 2017 @ 14:24:12

On the Laravel News site there's a new post sharing some of the new Blade directives coming in the 5.6 version of the Laravel framework.

Laravel 5.6 will include two new form blade directives for cross-site request forgery (CSRF) and HTTP method input, thanks to Taylor Otwell.

The new CSRF handling replaces the previously used format with a simple @csrf tag in the Blade template (inside of the form). The other is related to the method used to submit the form. The new addition allows you to submit the form via something other than POST using the method_field function.

tagged: laravel blade feature upcoming template csrf method submit

Link: https://laravel-news.com/new-blade-directives-laravel-5-6

Mark Baker:
Extending final Classes and Methods by manipulating the AST
Nov 20, 2017 @ 10:38:32

Mark Baker has an interesting post to his site where he shares a suggestion for making it easier to create unit tests for some of the more difficult parts of your unit tests. In the article he shows how to extend final classes and methods by manipulating the AST (abstract syntax tree structure) of the current code under test.

We know that we should always write unit tests for our code, and mock dependencies; but that isn’t always easy when we need to mock classes define as final, or that contain final methods. This isn’t normally a problem when we’re only working with classes within our own libraries and applications, because we control whether they are final or not, and we can type-hint these dependencies to interfaces. However, when the dependencies that we use are from external libraries, we lose that control; and it can become harder to test our own classes if we do need to mock final classes and they haven’t been built to interfaces.

He talks about how one tool, Mockery, allows some of this with its functionality but can still cause issues when mocks are passed instead of actual class instances. He then starts on a solution he has been trying to implement - a mocking library that makes use of the PHP_Parser package to make it possible to modify the structure of the code itself, not just put a wrapper (mock) around it. He includes a bit of code showing how to use that and the BetterReflection library to do some class introspection, locate files for testing and how to the tool to "de-finalize" a class (make it no longer "final").

tagged: extend class method manipulate ast testing unittest final mockery tutorial

Link: https://markbakeruk.net/2017/11/19/extending-final-classes-and-methods-by-manipulating-the-ast/

Stefan Koopmanschap:
Your unit test methods need docblocks too
Oct 12, 2017 @ 11:48:02

In a post on his site Stefan Koopmanschap suggests something that, while not as commonly done as writing docblocks for the actual code, could help with a better understanding of the application's tests: writing docblocks on tests too.

If you've met me at any time in the previous 20 years and you discussed unit testing with me, chances are pretty big that I'd have told you that your test methods in your unit tests don't really need docblocks, because the test methods would be named in such a way that they were descriptive.

[...] Tests can be hard to real though, especially (but not exclusively) when testing legacy code. You may have lots of mocks to configure, for instance, or you may have several similar tests that are testing specific situations, edge cases or bugs you found along the way that you wanted to test before you them.

[...] Documentation is important. It lowers the bus factor, makes it easier to on-board new developers (or temporary external developers, waves) and makes you think about your own code in a different way. We're (getting?) used to documenting our software, but why not document our tests by giving it a bit more context?

He starts by talking about his process for testing (outline the desired tests then fill them in) and how adding docblocks helped him avoid a "nonsensical" test that wouldn't have provided much value. He then briefly discusses what would be useful to document in the test docblocks and provides some examples to illustrate. Finally he suggests something called "Docblock Driven Testing" where the docblock descriptions help to define what is to be tested and help to make more human-readable sense of what can be tested effectively.

tagged: unittest method docblock opinion testing definition

Link: https://leftontheweb.com/blog/2017/10/11/your_unit_test_methods_need_docblocks_too/

Don't call instance methods statically
Jul 25, 2017 @ 11:16:39

In this new post on thePHP.cc site they talk about calling instance methods statically, more specifically that it should be avoided.

There are quite a few things in PHP 4 that were a bit strange. One example is that PHP 4 allowed static calling of instance methods. [...] To keep backwards compatibility with PHP 4, this code works up to PHP 5, even though [the method in the example[ is not declared static.

[...] Now things will get really weird. When calling an instance method of another class statically, the $this context would carry over from the caller to the called class. In other words, $this suddenly refers to another object instance. While in PHP 5, this used to be an E_STRICT error, PHP 7 will emit an E_DEPRECATED error.

They point out that, while this is definitely odd behavior that shouldn't exist, it hasn't been removed because of PHP's backwards compatibility principles and only removing functionality like this in major versions. So, instead, they recommend calling all non-static methods using an instance of the class injected rather than directly calling them.

tagged: instance method call static object avoid error

Link: https://thephp.cc/news/2017/07/dont-call-instance-methods-statically