On the Laravel News site, there's a post talking about a feature that's coming in PHP 7.4: typed properties. It covers some of the basics of what they are and how they can help improve your code.

The Typed Properties 2.0 RFC was accepted with a vote of 70 in favor and one no vote. A 2/3 majority is required because typed properties is a language change. The typed property change is a PHP 7.4 proposal.

The post quotes the purpose of the feature from the RFC and provides an example of how most developers ensure property type safety now: via getters and setters. They then show a refactored version of this with typed properties, making for a much shorter class definition. They also include a code snippet showing all of the possible types you can use with the typed property functionality. They finish the post with a few of their own thoughts about string typing versus weak typing in PHP and link to the pull request that's in progress to implement the feature.

Matt Sparks has posted a tutorial to his site introducing one of the more powerful but often misunderstood parts of the PHP language: its Reflection functionality.

Beginning work on the Analyze PHP framework, specifically the container, brought reflection to my awareness. Before that I had maybe heard the term, but I definitely hadn’t used it intentionally. Although it sounds like a scary computer science concept, it’s not. It’s actually quite simple:

Reflection is the ability of a computer program to examine, introspect, and modify its own structure… That’s it.

He starts the tutorial by introducing some of the basics concepts behind reflection in PHP and what it has to offer. He then shares some code examples of it in action getting class properties and getting the constructor. He also shows the use of other built-in PHP functions getting the class methods and the class name.

As a part of his "Advent Contribution" series Derick Rethans has posted about an update to XDebug that fixes a bug reported around hidden properties.

This first contribution is for bug #987: "Hidden property names not shown". In PHP it is possible to convert an array to an object. [...] Xdebug's standard HTML var_dump() as well as the CLI, the coloured CLI and the debugger interface DBGp all suffered from the same issues that numerical properties were not showing in output.

With the committed fix the output of the var_dump now shows these special property names with curly braces around them and makes them available via the property_get method. If you're interested in the actual commit, you can check it out here.

In this recent post to DZone.com Giorgio Sironi talks about how, despite it commonly not being intended this way, configuration files usually end up being "code".

You start out with a simple .ini file [and] after a while, you customize its values by deployment environment. [You] then substitute values in it, to remove duplication or substitute constants, for that matter. Finally, you start supporting dynamic values, because this gives you more flexibility. The thesis of this article is that an efficient solution for supporting the more complex use cases of configuration can be found, without piling up proprietary or open source libraries to parse more and more complex configuration files. This solution, namely, is to use a more powerful language: your own dynamic programming language.

He looks at the "back in the day" configuration types that Java frameworks used - mostly XML files with a tight coupling to the servlet using it. He steps back a bit and looks at what he calls the "properties of code" and relates it to this dynamic language for configuration he's been talking about.

In a new post to his blog Chris Hartjes, promoter of all things testing, looks a a method for testing constructors - an effective way to validate the things that happen when your objects are generated.

If you have a PHP application that makes heavy use of objects (which is probably 95% of you reading this) then you will have objects with constructor methods in them. It is also very likely that there is some stuff going on in those constructors. So how do you test things like this?

He includes a sample constructor that creates a container, pulls out some configuration values and reassigns them to class properties. He first tests that these properties have been set correctly by mocking out the object and overriding the configuration settings in the (dependency injection) container.

In a new blog post Jani Hartikainen shows how to create an abstract model that you can build on when you need to make a dynamic model for your framework application.

In a usual scenario involving models in PHP, you will have some repeating things: You will usually need getters and setters for the model’s properties, you will need to be able to construct the model from an SQL query or such, and you’ll also need to write SQL queries for the models.

He builds up the three different parts of the abstract model - the getters/setters, fleshing out the model by defining its properties from array values and creating some dynamic SQL (based on property names).

Tobias Schlitt has posted a handy tip about using the Reflection API in PHP5 - specifically its accessing of private properties in a class.

I recently stumbled over reflecting private properties in PHP again. As you might know, this was not possible until now and if you tried this [code] PHP thanked it to you with this [error that is cannot access a non-public member].

He notes that, while the behaviour is correct, it still makes things like metaprogramming impossible. So, what's a developer to do? Patch it of course! Tobias and Derick Rethans persuaded two other developers (Derick and Marcus Borger) to include a patch that allows the Reflection API to see these private variables.

To make it work, you have to use the setAccessible method on the Reflection object to set which of the properties you want to be able to get at.

Stefan Mischook shares a little question and answer he had recently concerning object properties in PHP.

The question asked about accessing properties outside the class and/or defining them as protected/private to prevent it. Stefan's response was basically:

Many OO techniques are designed for situations where you will have more than one programmer involved, now or later. By declaring variables as protected or private, you are adding security to the code base by forcing the use of getter and setter methods where you can control how objects are used.

Stefan Mischook shares a little question and answer he had recently concerning object properties in PHP.

The question asked about accessing properties outside the class and/or defining them as protected/private to prevent it. Stefan's response was basically:

Many OO techniques are designed for situations where you will have more than one programmer involved, now or later. By declaring variables as protected or private, you are adding security to the code base by forcing the use of getter and setter methods where you can control how objects are used.

In response to this previous post from Jeff Moore, Tobias Schlitt shares some of his own comments on the subject - mainly that he wholeheartedly agrees.

The usage of interceptors (__get()/__set()/__isset()/__call()) makes your API a lot more readable and comfortable, while maintaining the purpose behind getters and setters: Checking the correctness of values assigned to a property and wrapping around retrieval mechanisms for a property. I personally call the way of maintaining value-correctness for properties through interceptors virtual properties, which fits quite nice I think.

Tobias gives an example of what he means by these "virtual properties" with an illustration from something widely used on the eZ Components libraries - comparing one method of setting text to an object to another (just setting versus the wrappers).