On Mon, Feb 27, 2012 at 12:15 PM, Kris Craig <kris.cr...@gmail.com> 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). > - 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. > - 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. > > 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. > > Whether this should be done at the function level, the variable level, or > both is an open-ended question. > > > Some possible examples of how this would look: > > weak int $i = "aaa"; // Converts to 1 and throws a warning. > strong int $ii = "aaa"; // Throws a fatal error. > weak int $i = "1"; // Converts to 1. > strong int $ii = "1"; // Converts to 1. > > > --Kris > > Maybe this discussion should start from the end of the last discussion on non-strict type hints, where really smart people came up with some options to handle the conversion: https://wiki.php.net/rfc/typecheckingstrictandweak#option_1_current_type_juggeling_rules_with_e_strict_on_data_loss The RFC talks about throwing E_STRICT or E_FATAL, and has a couple of options for a matrix of conversion rules. I don't think we need another name for weak type hints, since the name covers anything less than strict, and anything more than none. There's been enough confusion about the names of things without adding another name for a variation of weak type hints. If I recall, the previous effort died due to the emotional stress of getting to the point where the differences between strict type hints and non-strict type hints was well understood, and everyone's position on those two points was crystallized. There were still a few proponents of strict type hints, but it seemed they were willing to live with non-strict type hints. At that point, everyone became more interested in having a 5.4, and scalar type hints were left for a time. Hopefully I haven't mischaracterized anyone's position, but I hope it helps us move beyond previously trod ground. John
