On Mon, February 27, 2012 1:15 pm, Kris Craig wrote: > Now, to rewind a bit past the latest chunk of "I hate this idea" > posts.... > > I'd like to suggest a new term: "strong". > > This term would be similar to "weak", except with a few key > differences: > > - Weak would behave very much like Arvids suggested in his earlier > post; > i.e. if the variable is an integer but you pass a string (like > "aaa") to > it, a warning would be thrown and PHP would attempt to convert it > (i.e. it > would become 1).
Nitpick: Two backwards compatibility breaks: 1) Throwing E_WARNING 2) "aaa" converted to (int) is 0. > - Strong, on the other hand, would throw a fatal error if you > attempted > to pass an incompatible value to an array. Or, to put it another > way, if > the "converted" value does not match the original value. For > example, if > we're assigning "aaa" to an integer, that would convert to 1; and, > since > "1" != "aaa", a fatal error would be thrown. On the other hand, if > you > were to pass the string "1" to that integer variable, it would > convert to > 1; and, since "1" == 1, there wouldn't be a problem. Converting "aaa" to 1 causes the error... Converting "aaa" to the backwards-compatible means "aaa" == 0 will return TRUE, and your test for reverse engineering will not help. This is still a nitpick, as I'm sure you could eventually come up with some way to validate your strict-ness of conversion. It would be more cumbersome and slower than using PCRE or ctype_* to validate or === to guarantee the data types match. But you can do it. And I'd love to see an extensive patch in an RFC rather than this endless back-and-forth. Neither Stas nor I are saying it shouldn't be done. We're saying it's been tried and failed, but if you want to be the little engine that could, the proper place is in an RFC with a community-drive patch that can be evaluated on technical merit. > - In both instances, if the converted value matches the original > (i.e. > "1" == 1), no warning error would be displayed. Should it perhaps > display > a notice though? Or no error at all? I can think of reasonable > arguments > on both sides of that question. I'm pretty sure backwards-compatibility is going to trump, and "no error at all" will win out. > This new term would also make it easier for us to avoid using the term > "strict," which would explode even in the case of "1" == 1. This is a good idea to distinguish between strict typing throughout, and judiciously applied strict typing. I fully support calling it "strong" for clarity purposes. > Whether this should be done at the function level, the variable level, > or > both is an open-ended question. > weak int $i = "aaa"; // Converts to 1 and throws a warning. What purpose would 'weak' serve? If you want the old default behavior, just leave out the 'weak'. And we already have (int) $i = "aaa" // converts to 0 as ztype int. Or perhaps I'm missing something where 'weak' is supposed to invert the current logic of "aaa" -> 0 and you actually want it to be 1 and not backwards compatible? I must be missing something here, then, because that just plain doesn't make sense to me, personally. > strong int $ii = "aaa"; // Throws a fatal error. Okay. E_FATAL seems drastic to me, but I'm not even going to use "strong" so don't really care either way, I suppose. I can always set my error handler to over-ride the level of your error, and even pick out the specifics to change it to whatever I want... I respectfully suggest you'll want to discuss the actual level of error among proponents of the strong typing, and put the consensus in the RFC. > weak int $i = "1"; // Converts to 1. Again, old-school (int) or set_type covers this. Adding new keywords to fulfill the same purpose seems like bloat to me... > strong int $ii = "1"; // Converts to 1. Okay. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
