I cannot say that i agree with the core message of this article. This is written from a mathematical standpoint, when in the majority of cases (at least in PHP) you are expressing semantic facts that are part of a model, not mathematical formulas.
A very important thing to understand when dealing with PHP is that you are not writing kernel-modules or 3D-engines or DBMS's or other performance-driven programs with it. You are using PHP for web-shops, for blogs or for accounting-, advertising- or logistics-web-apps. You are using it for model driven development, for software that tries to emulate a part of "real-life", and that is where semantics are king. The reason why high-level programming was invented was to give us better tools to express the semantics of a model in programming.
In many cases i actually do want to know if something is empty, no matter the technicals. For example: I want to know if the shopping-cart of my user is empty, not if the shopping cart is equal to null (which does not make semantic sense as a sentence). I don't care if at that point my cart is an object, an array or a decimal. I also don't care if the cart is NULL or "0" or an empty array, in all cases the cart can be considered to be empty. Just tell me if the cart is empty or not.
The reason why i often prefer "empty" is that it directly expresses the semantics of the model.
The same argument applies to "isset", it is a semantic operator that tells me if something is there. If it is NULL, it is defined to be "not there", which is exactly what i want to know. In your example-code above, i find the "isset" variant way easier to read.
The PHP expression
if (isset($payload['username'])) ...
directly translates to "If the payload has a username, then ...", which is very easy to read and understand.
In contrast, the PHP expression
if (array_key_exists('username', $payload')) ...
translates to "If the payload has an existing key that is 'username', then ...", which is a lot more convoluted and harder to understand that the "isset" version. But more importantly, it is not a statement that is taken from the model. Who talks like that?!
An even better way to express a check for an empty cart would probably be methods (like "isEmpty") on an shopping-cart object, but in reality (and especially lagacy PHP codebases) you do not always have your semantics expressed in objects, sometimes you have to deal with plain old primitives.
I am onboard with trying to reduce the possible bugs, but this is in my opinion a bad trade-off. You are making the code safer against unexpected (scalar) types, but at the same time you are making it harder to read and to understand by other (mostly junior-) developers because the wording does not relate to the model anymore. That means that when other people try to modify the code (and they will!), they are more likely to be confused by the code and more likely to introduce bugs (compared to when they could just read the code like plain fact-expressing English).
If you want to prevent bugs then the most important thing to do is to make the program easier to understand, problematic corner-cases come second.
I don't care if at that point my cart is an object, an array or a decimal. I also don't care if the cart is NULL or "0" or an empty array, in all cases the cart can be considered to be empty. Just tell me if the cart is empty or not.
I didn't understand this. Could you provide me some sample code, thanks!
On your second paragraph speak for yourself... I develop a factory shop control app mostly on a LAMP stack with ERP integration on an IBMi DB2. Believe me there are plenty of use cases for high DBMS and performance-driven apps in PHP.
As for the sentiment of your comment, yes there are many times isset and empty are useful, and understanding of how they are used is the only requirement for using them. They're my preferred way to test because I know what to expect.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I cannot say that i agree with the core message of this article. This is written from a mathematical standpoint, when in the majority of cases (at least in PHP) you are expressing semantic facts that are part of a model, not mathematical formulas.
A very important thing to understand when dealing with PHP is that you are not writing kernel-modules or 3D-engines or DBMS's or other performance-driven programs with it. You are using PHP for web-shops, for blogs or for accounting-, advertising- or logistics-web-apps. You are using it for model driven development, for software that tries to emulate a part of "real-life", and that is where semantics are king. The reason why high-level programming was invented was to give us better tools to express the semantics of a model in programming.
In many cases i actually do want to know if something is empty, no matter the technicals. For example: I want to know if the shopping-cart of my user is empty, not if the shopping cart is equal to null (which does not make semantic sense as a sentence). I don't care if at that point my cart is an object, an array or a decimal. I also don't care if the cart is NULL or "0" or an empty array, in all cases the cart can be considered to be empty. Just tell me if the cart is empty or not.
The reason why i often prefer "empty" is that it directly expresses the semantics of the model.
The same argument applies to "isset", it is a semantic operator that tells me if something is there. If it is NULL, it is defined to be "not there", which is exactly what i want to know. In your example-code above, i find the "isset" variant way easier to read.
The PHP expression
directly translates to "If the payload has a username, then ...", which is very easy to read and understand.
In contrast, the PHP expression
translates to "If the payload has an existing key that is 'username', then ...", which is a lot more convoluted and harder to understand that the "isset" version. But more importantly, it is not a statement that is taken from the model. Who talks like that?!
An even better way to express a check for an empty cart would probably be methods (like "isEmpty") on an shopping-cart object, but in reality (and especially lagacy PHP codebases) you do not always have your semantics expressed in objects, sometimes you have to deal with plain old primitives.
I am onboard with trying to reduce the possible bugs, but this is in my opinion a bad trade-off. You are making the code safer against unexpected (scalar) types, but at the same time you are making it harder to read and to understand by other (mostly junior-) developers because the wording does not relate to the model anymore. That means that when other people try to modify the code (and they will!), they are more likely to be confused by the code and more likely to introduce bugs (compared to when they could just read the code like plain fact-expressing English).
If you want to prevent bugs then the most important thing to do is to make the program easier to understand, problematic corner-cases come second.
Thanks for your take Gerrit!
I didn't understand this. Could you provide me some sample code, thanks!
On your second paragraph speak for yourself... I develop a factory shop control app mostly on a LAMP stack with ERP integration on an IBMi DB2. Believe me there are plenty of use cases for high DBMS and performance-driven apps in PHP.
As for the sentiment of your comment, yes there are many times isset and empty are useful, and understanding of how they are used is the only requirement for using them. They're my preferred way to test because I know what to expect.