6/22/2023 0 Comments Php convert array to stringThis can lead to a runtime exception in some scenarios. I even used Psalm to document and validate that these keys are strings, and yet sometimes they are actually ints. Much of the code I wrote over the past several years assumed the keys would be strings if they were set from a string. Personally I have been professionally writing php code for about 20 years, and I am just now realizing this. I suspect the current behavior is not only unknown to them, but actually contradicts a current belief a good portion of them have about how it currently works. I suspect that the current behavior is not expected/known/understood by the majority of the reasonably experienced and competent php professionals. While changing a language to map to the perception of how people thought it worked is not automatically a good idea, and the idea of doing this should be met with some skepticism, I think in this case it makes sense. I suspect this is the cause of some rare bugs in many of those projects where the code expects those keys to be strings. I have a suspicion that most php code that uses arrays and sets keys from strings assumes the keys will actually get set to a string, in the cases where the code cares about the types. I know this sounds strange because developers are supposed to design for how the language currently works, but I do think I still have a point if you will hear me out. In this particular case, where string keys of arrays are sometimes converted to ints, while it is true changing this will break some code, the existing design is already the cause of many bugs in existing code that would get fixed if the design were changed. A decision to add Maps may or may not get delayed for some time and a decision to change arrays could be considered in the meantime. I would say that the decision to change arrays is not mutually exclusive to the decision to add Maps. Arrays as they are in php are quite useful and improving them further in this way, if it is agreed this really would be an improvement, is something to consider. I'm not completely opposed to the idea of introducing a new Map object, but at the same time, I don't necessarily think that is more likely to be introduced or used, and it may not have all the benefits that arrays currently have. While those types of changes should not be taken lightly, it is also true that having to make changes to existing project code as backwards incompatible changes are made to the language is just part of software, and is sometimes worth it to make improvements to the language. Backwards incompatible changes do make their way into the language sometimes, and I think this is a case that warrants at least considering it. However, I personally still see merit in the idea of at least considering whether this should be changed. I ended up realizing this later after doing more research on it. More realistic is introduction of new Map object. This is 20 years old design, and changing that would likely break a lot of apps. Therefore as is, this design causes using anything other than an int as the key to be a bad practice, which means you would then have do something much more complex like store an array of arrays of keys and values instead of just using the keys as the keys and the values as the values. Even if psalm were adapted to be able to catch this, it would have to become more complicated, and the types declared in the code to help psalm would become much more complex, your code itself becoming more convoluted. These are the types of runtime exceptions a tool like psalm should be able to catch and help the programmer prevent, but this design makes it much more complex of a problem to detect. This can lead to an exception at runtime in simple situations like a function with a return type of string that ends up returning a particular key when it expected all the keys to be a string. It also means that when using tools like psalm, when you type the key as string, it might actually not always be a string, and psalm won't be able to statically detect that you are storing the wrong type for the key because you are not, php is. This effectively means that when using the key later, if it is both expected and required to be a string, it will have to be cast to a string just in case it was converted to an int by php. Often when the programmer is trying to use a string for the key, there is some chance that it could be a valid int. This design effectively makes it so that we often cannot be guaranteed what type to expect for the key. If the type that was used for the key started out as one of the two valid types, either int or string, neither the type nor the exact value actually stored as the key should change for any reason.
0 Comments
Leave a Reply. |