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.

Lorna Mitchell has a post on her site that wants to help you out when Composer reports a "lock file out of date" warning when you try to update your Composer dependencies. She provides three options to help resolve this issue.

Composer is dependency management for PHP, and it consists of two main files: [composer.json and composer.lock]. Crucially, the composer.lock also includes a hash of the current composer.json when it updates, so you can always tell if you've added a requirement to the composer.json file and forgotten to install it.

The post includes three different ways to correct the warning message:

• Option one: upgrade all of the things
• Option two: try to work out which composer.json change caused this
• Option three: do nothing, safely

The first two options are preferable to the last one (essentially overriding the error) but it could be used in cases where you think Composer is just getting things wrong.

Matt Stauffer has a new post to his site today showing you how to extend Laravel's Application class to enhance its handling with other handy features.

It's seldom that we need to extend Laravel's core, and even when we do, it's most likely we're going to extend specific components, which is detailed in the docs. However, all of these instructions presume you're using the core Laravel Application (IOC Container) to extend the other classes. What if you want to extend the Application itself?

The example he provides is from his own real-world experience, based around changes they wanted to make in the default folder paths for things like the "storage" or "public" directories. He shares the three simple steps to making this custom handling work:

• Extend the class
• Register it in your application's bootstrap
• Override/extend the current methods to add in your own functionality

In this case, changing the default paths is something that's under discussion already, but it gives a good simple example of changing that default functionality.

In his latest post Rob Allen shows a way you can override the default Twig date filter with your own custom Date extension handling.

In one project that I'm working on, I'm using Twig and needed to format a date received from an API. The date string received is of the style "YYYYMMDD", however date produced an unexpected output. [...] This surprised me. Then I thought about it some more and realised that the date filter is treating my date string as a unix timestamp. I investigated and discovered the problem in twig_date_converter.

He includes some example code you'll need to create the custom renderer. As part of the internals of how Twig formats the date currently is internal and can't be changed, he opted to override the extension itself. As a result, the call to the filter is exactly the same as before, the output results are just formatted more correctly.

Rob Allen has posted a quick hint about overriding validation messages in a Zend Framework v2 based application. This override is related to the output of a standard form and works globally instead of just on a single form.

One thing that I always do when creating a Zend Framework 2 form is override the validation messages for a number of validators – EmailAddress in particular. I recently decided that I should probably sort this one out once and be done with it. Turns out that it’s quite easy assuming that you use the FormElementManger to instantiate your forms.

The post includes all the code you'll need to do the override: a custom validator example, the changes you'll need to make to the configuration and an example of a form that uses the custom handling. He explains each of the parts too, showing how they fit together in your module.

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

Kim Rowan has recently posted this helpful hint to the PHPWomen.org site concerning the addition of values between save/serialization in Symfony (1.4) forms.

OK, I have a Comment model and I want to relate Comment objects to several other different model types. So, I need to be able to persist Comment objects in my database that relate to the author of the comment and one of a handful of other tables, for example, a blog post or a licence record, etc.

She includes the contents of her "schema.yml" definition and the code to create and display a basic form. Inside of her "executeCreate", the form's submission is handled and a "processForm" method is called and the overridden "updateObject " is used to inject the new data (a user ID) into the submission.

In a quick new post to his blog, Rob Allen shows how you can override a module's configuration in a Zend Framework 2 application. In his example, he uses the "User" module and overrides two of the "magic paths" it creates.

Let's say that you install the ZF-Common's User module. By default, it sets up its routes under the /user path segment. [...] This config section will create the routes /user and through the magic of child_routes, also create /user/login and other required routes. If you don't want /user and would prefer /member, then it's easy enough to change. Just add a new config file to the project's config/autoload folder.

Code for the configuration files is included with the update to the "ZendMvcRouterRouteStack" to change the ZF-Common User module's setup to point to "/member" instead of "/user" when routed. You can find out more about the module system in ZF2 in the latest version of the manual.

On the Drupal4Hu.com site there's a recent post with a complaint about the OOP functionality in PHP and how Drupal developers should deal with its limitations.

While I was always complaining of PHP's inability of adding a method run-time, the problem we face is that you can't replace one either. So if you do what I did in the previous post, namely use the hook-alter patten (already an addition to PHP, I must say) to override the classname, that works. However, if two modules try to do this for two different methods, you fail.

He suggests to those Drupal developers out there that, for version 8 of the popular content management system, they drop the "closed crap that in PHP is called OOP" and work to make something better, implemented themselves. Something that would make it simpler for Drupal developers to create hooks into the main system for their plugins. Be sure to read the comments for other opinions on the post.

Craig Buckler has added a new post to the SitePoint PHP blog today that looks at some of the PHP configuration options and how you can change them from two different places (besides the php.ini file).

Configuring PHP is easy. You can change almost any aspect of the interpreter within the php.ini configuration file, e.g. modify error handling, increase memory usage, etc. Unfortunately, problems can occur when you move your application to a live hosting environment or are distributing the code to customers. ISPs usually lock down the php.ini configuration file - especially on shared hosting. This could cause your application to fail.

If you're lucky enough to be able to use htaccess files, his first method will work for you - using the "php_flag" or "php_value" directives to change settings for your entire application. The other option is more on an as needed basis - using the ini_set method to change configuration options. Be careful, though, only some configuration options can be changed using these methods. Some still require changes to the php.ini and a restart of the web server.