Sometimes I call this "loose equality" (==) and "strong equality" (===) but regardless of what you call it, the inclusion of loose equality is one of the most maligned features of PHP. Traditional programmers say using loose equality operators is a terrible practice - and for the most part, they are right. In general, when you are checking if two variables are equal, you really mean to check if they are identical. In other words, a string should not equate with an integer, even though they may *look* the same to a human.
However, what traditional programmers tend to miss is that one of PHP's strengths is the ability to be portable. Strong equality is one of the things that breaks portability. Therefore, assuming you are validating input and working in the realm of positive integers (non-zero), loose equality is the only way to go!
An example of this issue came up for me recently as I was moving my code from MySQL to Azure/MS-SQL in Laravel 5.3. For whatever reason, when queried from MS-SQL, integer column values may be returned as either integers or strings. This does not happen with MySQL! So suddenly two values that you'd expect to be identical are only *equal* (one is a string, one is an integer). I don't know if this is a quirk only with MS-SQL but when data sources disagree on how to return data it argues in favor of using loose equality for portability over strong equality (and bugs!).
I will say that Laravel has ways to ensure repository data typing, called "accessors". Accessors allow you to specify how data gets returned from an Eloquent model. They can be especially useful if you want to "friendly format" a date (like, "2 days ago" versus the actual date). However, defining accessors for every integer value in a large database can be a monumental task that is not even necessary for all platforms. With that in mind, loose equality can be very useful in avoiding bugs based on varying data type.
Of course, it is fair to still expect programmers to validate user input and sanitize or type cast. When dealing with user input, strong equality is definitely the way to go.
However, what traditional programmers tend to miss is that one of PHP's strengths is the ability to be portable. Strong equality is one of the things that breaks portability. Therefore, assuming you are validating input and working in the realm of positive integers (non-zero), loose equality is the only way to go!
An example of this issue came up for me recently as I was moving my code from MySQL to Azure/MS-SQL in Laravel 5.3. For whatever reason, when queried from MS-SQL, integer column values may be returned as either integers or strings. This does not happen with MySQL! So suddenly two values that you'd expect to be identical are only *equal* (one is a string, one is an integer). I don't know if this is a quirk only with MS-SQL but when data sources disagree on how to return data it argues in favor of using loose equality for portability over strong equality (and bugs!).
I will say that Laravel has ways to ensure repository data typing, called "accessors". Accessors allow you to specify how data gets returned from an Eloquent model. They can be especially useful if you want to "friendly format" a date (like, "2 days ago" versus the actual date). However, defining accessors for every integer value in a large database can be a monumental task that is not even necessary for all platforms. With that in mind, loose equality can be very useful in avoiding bugs based on varying data type.
Of course, it is fair to still expect programmers to validate user input and sanitize or type cast. When dealing with user input, strong equality is definitely the way to go.
Comments
Post a Comment