Declare static types to keep bugs away?

Declare static types to keep bugs away?


A lot of programmers feel that for any larger projects static types offer a huge benefit.
Readability too, not only validation.
Some argue that tests can replace types, I agree if we are only talking about code validation.
But static types are empowering in other situations too. Reading code is easier since types describe code and fewer assumptions have to be made about inputs and outputs. Basically, additional documentation which is always in sync with the code.

What about functional style?

In the last iteration of talk about improving correctness and avoiding bugs, we tried to do things in a functional way.
We tried to use some “higher” level constructs and to bring some benefits of functional programming with PHP, but in all honesty, it simply does not look so nice with currently available syntax.
I am still confident semantic benefits are real, but I am unsure because all that visual noise makes it hard to actually read and understand the code.

Here are 2 RFCs that would probably help a lot:

Since the chance of getting sexy syntax soonish is not so great (I hope PHP will get there) and closures do not automatically detect used variables and you have to list them explicitly let’s try something else.

Static types and immutability

2 obvious improvements which fit into low hanging fruit category: “immutability” and “strict typing”. Since I feel that being familiar with type systems will help in understanding huge benefits of immutability, let’s examine what kind of empowering restrictions can we place in our code!

I believe that benefits of static types rise with the complexity of software being written.
For example, I feel that Magento 2 would benefit a lot from static typing.

Humans have limited working memory. So, when writing software we can help ourselves by making code easier to understand. Having smaller pieces which operate on some contracts makes it simpler to both create and assemble those pieces. Static types bring a benefit of knowing what type of variable we have and which type of variable we need to return.

Input and Outputs

Functions should be tight in their return types and values and it can be argued that they should be wide in parameters accepted.
Functions which have return type being different depending on some logic flag can be hard to debug. Especially if error propagates further into the code and you gotta re-run debugger quite a few times to even get an idea about “how did that value get here?”.
With PHP7.0 we got the ability to declare return types on functions:

It looks and works OK, but it can be improved in some ways (from what I got by quickly skimming past versions of RFC, those issues could be covered).
First missing part is that it should be OK to tighten return type. (Only part of child classes, less generic)
This does not work (yet??):
Forgive me for bad OOP example 🙂

class Implementation {}
class BugFreeImplementation extends Implementation {}
class Software {
	public function produce() : Implementation {
		return new Implementation();
class DifferentSoftware extends Software {
	// Does not work
	public function produce() : BugFreeImplementation {
		return new BugFreeImplementation();
class DifferentSoftware extends Software {
	//Works, but consumers of our new and better method of producing software
	// can not know it is bug-free
	//Fact that it indeed is bug-free is just an implementation detail!
	//Program to interface, not to implementation!
	public function produce() : Implementation {
		return new BugFreeImplementation();


What are benefits of this? We are guaranteed that whenever we call product function, we will have a variable of type Implementation.
It will not be an array of somethings, a string or a null.


While we are on the topic of null, there is actually RFC for that.
This would work like Option, Maybe or however they are called in other typed languages.

If the return type is ?Implementation, it can either be a null or Implementation AND NOTHING ELSE!

Powerful in cases where you call a function which may or may not return a value.
For example, retrieving a single entity from the database.

Hopefully, we will be able to use such type system improvements in future versions of PHP.

In all honesty: enforcing static type rules on large projects is a quite large improvement.
But, having more powerful type system would help a lot and make it easier.
PHP DocBLocks allows some of that power but does not really enforce it.

Classes vs Traits

I actually hoped to include traits in this post, but I think it is better to handle them separately.
Traits are really useful building blocks which we can use to compose classes.
While it may not initially seem so, when I think about their usages, they often overlap with dependency injection.
So hopefully, in next post we will cover traits, then a little on benefits on immutability and then perhaps an exploration of dependency injection and its benefits and drawbacks.


Reading Material:

Related Inchoo Services

You made it all the way down here so you must have enjoyed this post! You may also like:

Add static content in Magento Checkout address form Mladen Ristic
, | 2

Add static content in Magento Checkout address form

How to programmatically create customers in Magento 2.3.x Deni Pesic
, | 2

How to programmatically create customers in Magento 2.3.x

90% of Magento websites are running on unsupported PHP versions. Why is this a problem and how can you (we) solve it? Aron Stanic
Aron Stanic, | 8

90% of Magento websites are running on unsupported PHP versions. Why is this a problem and how can you (we) solve it?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <blockquote cite=""> <code> <del datetime=""> <em> <s> <strike> <strong>. You may use following syntax for source code: <pre><code>$current = "Inchoo";</code></pre>.

Tell us about your project

Drop us a line. We'd love to know more about your project.