Skip to main content

My PHP Wishlist

PHP Wishlist

These are things that I think would help developers build better programs with far fewer lines of code. Simple enough? Let's get to it.

Scalar Type Hints and a Strict Mode

Currently one of the hottest RFCs in PHP history perhaps, Scalar Type Hints. This is a feature that allows developers to specify any type a given parameter should be. Currently PHP only supports object types and arrays for type hinting. This allows for string, integer, boolean, and the like. 

However, nothing is simple in PHP. With this, some developers want conversion to happen if the wrong type is given (string to integer for example if '3' is passed in) while others want strict enforcing of types. The RFC has a middle-ground of loose typing by default like everything else in PHP, but the option to turn on a strict mode.

My issue with the RFC is... The syntax is horrible for declaring strict mode. I was actually entirely for it up until a few days ago. I read a comment on Reddit. This person describes a "strict" keyword that could be used on classes, their methods, or functions to declare the properties to be strictly checked. I much prefer this solution. I wouldn't go as far as to say a "weak" keyword too. Or even to define strict/weak at the individual property level. Simply say this is strict, or it isn't. Default to weak, strict is opt-in at the class, method, or function level as desired.

I believe at this time, the RFC should fail. Another should be made that adds scalar type hinting with standard type conversion if the wrong type is given. Then we can look over different syntax choices for adding strict type hinting and add that in later, even in a minor version of 7.x if it can't land before 7.0 drops.

Property accessor syntax

Property accessor syntax makes a simpler way to define how a class property should be read and saved to. There is already a failed RFC that attempted to get this into PHP. From what I understand it was mostly rejected due to an implementation that internals didn't feel was clean/maintainable/whatever.

Currently there are two primary ways properties are manipulated. The first is to define a custom getter/setter for each property and set the logic in those. The second is to use magic methods to check for the property and set/get it. Having direct accessor syntax simply makes code cleaner and more legible.

Decimal number type

This is a much more difficult and long-reaching ask to be integrated. Currently PHP offers integer and float types. Integers store whole numbers only and float stores decimals, but not guaranteed complete accuracy. Also when compounding operations with floats, things can get worse. While bcmath functions are available, they use strings for parameters over a proper number type. Further, they are function calls instead of normal math syntax.

To fix this, I would like to see a decimal type added. One that is built on something that can accurately use a single number type to represent whole numbers and decimal places. Where we are able to use normal math operators to accurately calculate results, even in complex operations.

One implementation that could be used for a decimal type is DEC64. Created by Douglas Crockford and announced at HTML5 Dev Conf. This is a method aimed at fixing computer number storage so decimals are accurately represented. To be honest though, I have no clue how to really verify this and make sure it is good. It just sounds like a nice implementation that could be used.

Getting a new number type would be very involved to make sure everywhere data can come in has the option to be decimal. Further you wouldn't want to add it to loose typing structures either since that would cause legacy issues. Because of these issues (and more) it will probably never happen, but I can dream.

Conclusion

These are three major points that I see being helpful to everyday developers. With these we could build more well structured applications with significantly fewer lines of code.

Updates!

  • Added to the end of my thoughts on scalar type hinting and how I think it would be best to proceed.
Labels:

Popular posts from this blog

Laravel, Codio, and Nginx

I have recently come across a *sweet* online IDE, this would be Codio . Codio lets you develop in the cloud and run the code on an actual server. This way you can write your code and run it in the cloud, keeping your development environment universal and in my case safe-guarding against my own nonsense. While Codio does offer their own  documentation  on getting Laravel going, it uses Apache and MySQL. So here is getting going with Nginx, MariaDB, and PHP-FPM on Codio for Laravel development. Create your project Create a project just how you normally would, except select "Git" as the method for getting the base code into the workspace. This will give you an input where you can either put in an HTTP or SSH based git repository URL. If you are using SSH and you haven't setup the SSH key on your repository, it will prompt you to do so automatically with a key Codio generates. For now, I'm going to just use the standard HTTP URL for Laravel which is https://github.co
Post a Comment
Read more

You may not need meta charset

It is generally accepted that web pages should have a meta tag to set the charset of the document. However, you may not need it. The HTML5 specification clearly states that when  determining the character encoding  that if it is found in a content-type header attribute, then the engine should no longer look for one in the document or anywhere else. You can set the header either in your application logic or in your server configuration ( Apache  and Nginx examples). So what does this mean for developers?  Well, we all know performance matters. Let's say after gzipping your content this declaration adds just an extra three bytes of data to your page. Across millions of requests around the web per hour which leads to billions per year, that ends up saving a lot of space. Not only that, but think about how the network functions. Packets on the internet have a set amount of space. This is called the  maximum transmission unit  size. It is generally at 1500 bytes per packet for e
Read more