Matt Sparks has an interesting post to his site sharing something he'd like to see in PHP 8 (quite a ways off in the future but still worth thinking about): scalar objects.

Recently, I read an interesting article from Andrew Carter entitled Make PHP Great Again [cheap plug: this link was included in my most recent Newsletter]. In it Andrew brought up the topic of scalar objects. If you’re not familiar with scalar objects, they represent a single value (integer, boolean, string, etc.) that you can perform operations on*.

He shares an example of what it might look like in PHP and his response to a tweet from Nikola Posa about what features they'd like to see. He then spends the remainder of the post making his case for the inclusion of scalar objects and how it can help clean up some of PHP's own naming and functional inconsistencies.

The Zend Developer Zone has posted the second part of their series (from community member Larry Garfield) about scalar types in PHP 7, one of many features in this "coming soon" release. You can find part one of the series here.

In our last installment, we talked about the benefits of more robust variable typing in PHP 7, and specifically the new support for typed return values. That is already a big boon to the maintainability of our code, but PHP 7 goes a step further. So far, we’ve only talked about typing against classes and interfaces. We’ve been able to type against those (and arrays) for years. PHP 7, however, adds the ability to type against scalar values too, such as int, string, and float.

But wait. In PHP, most primitives are interchangeable. [...] Much the same as return types, scalar types offer greater clarity within the language as well as the ability to catch more bugs earlier. That, in turn, can help encourage more robust code in the first place, which benefits everybody.

He starts by looking at the four new types that have been added in PHP 7: int, float, string, and bool. He includes a code example showing each of them in use on class interfaces and functions. He steps through the code example, explaining how the return type checking is handled for each instance. He also talks about how return type hinting can also benefit static analysis tools, allowing them to potentially find bugs in return values easier than before. Finally he covers strict mode, the method for enforcing types in your code and preventing PHP from doing any "magic" type switching for you. He also includes a code example of this functionality and how, with it enabled, it would have caught an error in his example on a integer vs string input.

Anthony Ferrara has tossed his own hat into the ring around the debate that's been going about the RFC for scalar type hints in PHP. In his post he agrees with (most of) the suggestions made in the proposal around strict, weak and the "compromise" of mixed typing.

There's currently a proposal that's under vote to add Pascal Martin's excellent post about it. What I want to talk about is more of an opinion. Why I believe this is the correct approach to the problem.

He starts off talking about the "all strict" angle that some suggested as the proper approach then moves into the "weak argument" explaining the difference between the two. He shares a bit of history around the problems detecting subtle bugs caused by typing issues and how it is definitely a problem that needs solving. Finally, he talks about the mixed-typing compromise and provides some code samples showing a common bug that can happen with weak typing.

Pascal Martin has a new post today sharing some of his thoughts around one of the currently proposed PHP RFCs for < href="http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html">scalar type hinting. PHP has had type hints for custom objects and some things like arrays but this proposal would add in additional ones for things like "string", "int" and "float".

The Scalar Type Hints RFC for PHP 7 has first been initialized in December 2014. It went on with version 0.2 at the middle of January 2015, after changing several major ideas, and is now in version 0.3, integrating return types, as RFC Return Type Declarations has been accepted a few days ago. [...] I’ve been following this RFC (and the previous ones) with some interest, and, as I’ve taken some time to play with it a bit last week, building PHP from the sources of the corresponding Git branch, I’ll try summarizing here why I think it is interesting. Please note this is my personal opinion.

He starts with a look at what the proposal entails around these new scalar type hints and why he thinks they're a good idea. He looks at some of the things that PHP's current weak typing allows and how it has made the language very flexible as a result. He also shows how the proposal suggests the use of the "declare" function to define a strict typing constant to essentially turn on the checking only where needed. He provides a few code snippet example including object/method handling, setting a custom error handler and which of the calls work in which typing method. He finishes the post looking at the "per-file" idea of enabling the strict typing checks and some of his confusion around the point. He also talks about return types, the directives that are proposed to enable the feature and the current status of the RFC.

In this new post to his blog Nikita talks about scalar type hinting and why it's harder than most people think to accomplish.

One of the features originally planned for PHP 5.4 was scalar type hinting. But as you know, they weren’t included in the release. Recently the topic has come up again on the mailing list and there has been a hell lot of discussion about it. Yesterday ircmaxell published a blog post about his particular proposals. The reactions on reddit were mixed. On one hand it is clear that people do really want scalar type hints, on the other hand they didn't seem to like that particular proposal.

He gets into some of the details of some of the current proposals and their problems like the strict versus loosely-typed nature of PHP and type hinting that was included but not enforced. One he does like, however, is one based on casting - how the variable ends up being cast rather than the specific type it is when it comes into the function/method. This one still has its flaws, so he suggests another method - weak type hints but with stricter input validation (without casting). He also briefly mentions something called "box based type hinting" that would allow users to define their own hinting rules.

Don't worry - code examples (pseudo-code obviously) are included for each of these proposals to help you understand the differences.

In the theme of other recent posts mentioning the scalar type hinting that has been included in the main line of code that is headed towards the next PHP release, Sebastian Bergmann has a new post about their inclusion in PHP 5.3.99 (yes, that's PHP 5.4) and the new syntax it introduces.

In a nutshell, this means that PHP 5.3.99 introduces new syntax -- scalar type hints -- but no new semantics. The latter can either be implemented as an extension written in C/C++, in userland PHP code, or in a tool that statically analyzes the code.

He includes an example fro userland with a "php_check_parameters" function that looks at the arguments of the current method and uses Reflection to check against the type hints for the correct value type.

Johannes Schluter has posted a bit more information about the scalar type hinting that's been included in the main development line of the PHP language (trunk).

Some time ago I wrote an article about the implementation of type hints for non-object types for PHP. Meanwhile many things happened and that implementation was replaced by a different one. Readers of my previous post might know that I have doubts about type hints in PHP.

He shows some of the example syntax for the hinting and points out how, in one case, there's no error thrown when the type hint is a native one but an error is thrown on a custom type hint.

So why is there a syntax added which is ignored? [...] Well, I let it to you to decide whether it make sense to have two syntaxes which look the same but do very different things (being ignored vs. throwing a terminating error) and whether it makes sense to push a system where the core language behaves differently depending on the system. [...] I seriously hoped PHP was out of the era of introducing new inconsistencies.

As Johannes Schluter mentions in his latest blog post, another new feature has been added to the trunk of the PHP project - scalar type hints.

So in my blog series I try to cover all additions to PHP trunk so I have to mention scalar type hints.

He gives examples of both simple hinting (ensuring a value is a float) and a more complex example setting an attribute on a PDO connection (checking for an integer). Sample error messages are included as well. He also gives some advice on mixing strong and weak typing in your apps - it's like "opening a can of worms".

In a new post today Patrick Allaert has continued his "Readable Code" series with some tips on how you can make your API handle more.

His suggestions include:

• Changing the handling to look for multiples by default
• Avoiding inner looping (repeated looping) and try for code reuse
• Transforming a scalar value into an array to make it easier to handle this way (by casting)
• and how to handle objects in the same array-handling kind of code

He also tosses in a little mention of performance, noting that a call with range in the argument to his array-handling method is faster than looping over the same range and calling the method each time.

Ilia Alshanetsky has a quick new post with some great news for some PHP developers out there - scalar type hinting has been introduced into the latest trunk of the PHP project.

About an hour ago, something I've been fighting for almost 2 years happened. The Scalar Type Hinting patch for PHP (the one I wrote almost a year ago) has been adjusted for PHP's trunk tree and committed by Derick.

You can see some of the type hinting features already included in PHP in the manual. This patch adds hinting ability for the other (non-object and non-array) variable types.