In this post to his site Matthias Noback makes the argument that, during your normal development, classes should be final by default and only changed if there's a need to extend them.

I recently wrote about when to add an interface to a class. After explaining good reasons for adding an interface, I claim that if none of those reasons apply in your situation, you should just use a class and declare it "final".

[...] For a couple of years now I've been using the final keyword everywhere (thanks to Marco Pivetta for <a href="https://ocramius.github.io/blog/when-to-declare-classes-final/>getting me on track!). When I see a class that's not final, it feels to me like it's a very vulnerable class. Its internals are out in the open; people can do with it what they want, not only what its creator has imagined.

Still, I also remember my initial resistance to adding final to every class definition, and I often have to defend myself during workshops, so I thought it would help if I explained all about it here.

He starts off by talking about the alternative - non-final classes - and some of the issues that can come with it (and class extension). He makes the suggestion that "replacing is better than overriding" and creates less complexity overall. He also answers a question about the use of the "Template Method" design pattern that would allow for improvement from base "skeleton" logic designed to be extended. He covers "composition over inheritance", the use case of extension and how "final" is a better direction.

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").

The PHP.net site has officially announced the latest (and final) Release Candidate for the upcoming PHP 7.1.x release: PHP 7.1.0 RC 6:

The PHP development team announces the immediate availability of PHP 7.1.0 Release Candidate 6. This release is the sixth and final release candidate for 7.1.0. All users of PHP are encouraged to test this version carefully, and report any bugs and incompatibilities in the bug tracking system.

[...] For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive.

As with the other Release Candidates you can grab the source download if this release from this QA site or the Windows binaries from the Windows QA site.

In response to a few other posts about the use of "final" in PHP development, Freek Lijten has posted some of his own thoughts and some of the things he came to realize about its use in his own development.

I read a blog by Brandon Savage a couple of weeks ago and it triggered some thoughts. He refers to a blog by Marco Pivetta which basically states "Final all the things!". Brandon comes back with a more mild opinion where he offers the notion that this approach might be overkill. Since both posts got me thinking I tried to organise my thoughts on this in the following post.

Freek talks about a pretty common trend in the PHP world: the very rare use of "final". He suggests that "extension" of classes is a bad idea (or at least should be used a lot less) and how he has seen it commonly misused. He then shares two reasons why he thinks "final" is a good idea, mostly centering around how easy it is and how the Open/Closed principle applies. In the end, he notes that he'll be trying to use more "final" in the future and see where it takes him and his code.

The latest (and last in the series) Release Candidate for PHP 7 has been released as mentioned on php.net today. This is a development preview release only and is not intended to be used in production.

The PHP development team announces the immediate availability of PHP 7.0.0 RC 8. This is the thirteenth pre-release of the new PHP 7 major series. All users of PHP are encouraged to test this version carefully, and report any bugs and incompatibilities in the bug tracking system. [...] PHP 7.0.0 RC 8 contains fixes for 11 reported bugs.

This release fixes several final bugs that were preventing the final stable release of PHP 7.0.0, some relatively major. You can download this latest release from either the QA download page or from the Windows QA site. If you're interested in what's changing in this release (and in PHP 7 overall) check out the NEWS file.

Mathias Verraes has posted some of his thoughts about using "final" in classes and what kind of impression it gives about your code.

I make all my classes final by default. I even configured the templates in my IDE prefix new classes with ‘final’. I’ve often explained my reasoning to people. A blog post is in order! A guiding principle here is Clarity of Intent. [...] The reason we need clean code, is not for the compiler. It’s to help our fellow developers, third parties, and even ourselves in six months time, understand the purpose and the design of our system.

He relates this concept of clean code and clarity back to the SOLID development principles, specifically the "Open/Closed Principle". This principle states that software should be open for extension but not for modification. It suggests that providing a stable, known API is a responsibility of the developer and using things like callbacks and listeners is a better way to extend. He gets into a bit more PHP-specific issues around using "final", including the difficulties that it can cause during testing.

In the latest post to his site Andrew Podner takes a quick look at something you don't see too much in PHP applications but is a familiar concept to some coming in to the language from others - using "final" to prevent overrides of the code in your classes.

In a previous post about inheritance, I showed you how to extend a class. One aspect of extending classes that wasn’t fully covered was the idea of overriding a method in a class. You can override a method (function) from the base class by simply redefining the method in the child class. [...] There are times though, when you do not want a method to ever be overridden. There may even be cases where you do not want a class to be extended.

His example shows how to use this "final" keyword on a database class, protecting a method (getRecord) that could potentially break the application if changed. This would then give the developer trying to extend the class an error noting that that method cannot be overridden. One thing to note, if you're going to use "final" in your code, be sure you know what you're doing. More often than not, you probably just want something like "private" or "protected" (see this post for a bit more explanation).

Matthew Weier O'Phinney has a new post to his blog today looking at visibility in OOP in PHP - less about the features the language offers and more about the theory of their use.

I'm a big proponent of object oriented programming. OOP done right helps ease code maintenance and enables code re-use. Starting in PHP, OOP enthusiasts got a whole bunch of new tools, and new tools keep coming into the language for us with each minor release. One feature that has had a huge impact on frameworks and libraries has been available since the earliest PHP 5 versions: visibility.

He covers a bit of the syntax and features of public, private and protected and mentions a keyword not often seen in PHP applications - final. The reason all of this came up was work on annotation support in Zend Framework 2 and some difficulty in integrating it with Doctrine support. The "final" status of the class was part of the problem, and after a a lot of copy & pasting he decided on a different tactic - using its public API to try to work around the problem.

In sum: because the class in question was marked final and had private members, I found myself forced to think critically about what I wanted to accomplish, and then thoroughly understand the public API to see how I might accomplish that task without the ability to extend.

The jsDay and phpDay conferences have just posted their final schedules and from the looks of them, they're both going to be great events!

Sessions from jsDay include:

• Backbone.js FTW! (Pierre Spring)
• JavaScript Application Architecture (Brandon Keepers)
• Ember.js - Focus on your app not on boilerplate code (Garret Alfert)
• Getting Started with Nodejitsu (Nuno Job)
• Go to hell Flash! We have Open Web! (Michal Budzynski)

Sessions from phpDay include:

• Test Driven Development with Symfony 2 (Jacopo Romei)
• Scalable architectures: Taming the Twitter Firehose (Lorenzo Alberton)
• Get'em in shape: let customers appreciate the agile workflow (Stefano Maraspin)
• An introduction to Phing the PHP build system (Jeremy Coates)

For more information about these events and to get your tickets, see the sites for each conference: phpDay, jsDay.

On the Symfony blog Fabien Potencier has posted about the roadmap to a final release for the Symfony2 version of the popular framework including some of the things that will and will not change after the release.

We are now ready to release Symfony 2.0 final. As we have made some significant changes in the last couple of weeks, we are publishing another release candidate (RC5) today and we will wait for a week before releasing Symfony 2.0 final on Thursday 28th.

The upgrade to Symfony2 is just a few commands away and there's a large list of components that are set and will not be changed moving forward including the DependencyInjection, Finder, Locale, Routing and Validator.

Symfony 2.1 will be the first release with all the components with a public stable API. And for components that already have a public API in 2.0, 2.1 will be the occasion to add even more classes and methods to it.