rfc:typecheckingstrictandweak

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
rfc:typecheckingstrictandweak [2010/05/30 21:45] – minor tweaks to handle the fact that we now have 3 different variations lsmithrfc:typecheckingstrictandweak [2011/04/06 10:59] – external edit 127.0.0.1
Line 62: Line 62:
 ^ NULL (NULL)               | pass   | pass   | pass   | pass   | fail   | ^ NULL (NULL)               | pass   | pass   | pass   | pass   | fail   |
 ^ %%''%% (string)               | pass   | fail   | fail   | pass   | fail   | ^ %%''%% (string)               | pass   | fail   | fail   | pass   | fail   |
- 
 ===== Option (2): new type juggeling rules with E_STRICT on data loss ===== ===== Option (2): new type juggeling rules with E_STRICT on data loss =====
  
-The here proposed auto-conversion would be a bit stricter than the now standard rules. For example it would not auto-convert from/to array's.+The conversion rules proposed here are slightly stricter than PHP'auto-conversion rules.  Mainly, the string "abc" will be rejected as valid input for an integer type-hinted argument, and not be passed-on as zero and it would not auto-convert from/to array's.
  
-An E_STRICT would be raised if due to auto-conversion there would be data loss. So for example "2", 2 as well as 2.5 would convert to a float if one is expected. However 2.5 would not silently convert to an integer if one is expected. Similarly "123abc" would not convert to an integer or float. This might also be a potential approach to type juggling in general in some future version of PHP+An E_STRICT would be raised if due to auto-conversion there would be data loss. So for example "2", 2 as well as 2.5 would convert to a float if one is expected. However 2.5 would not silently convert to an integer if one is expected. Similarly "123abc" would not convert to an integer or float. This might also be a potential approach to type juggling in general in some future version of PHP.
  
 Here is a short list of examples to illustrate the weak type hinting. Note that just like the current array/object hints, a NULL is only allowed if the parameter defaults to NULL. Here is a short list of examples to illustrate the weak type hinting. Note that just like the current array/object hints, a NULL is only allowed if the parameter defaults to NULL.
Line 97: Line 96:
  
 The auto-conversion would follow the current type juggeling rules. However in case of a cast that leads to data loss (like casting from '123abc' to an integer leading to 123 an E_FATAL notice would be raised. The auto-conversion would follow the current type juggeling rules. However in case of a cast that leads to data loss (like casting from '123abc' to an integer leading to 123 an E_FATAL notice would be raised.
 +===== Patch =====
 +
 +  * {{:rfc:auto_converting_type_hinting.diff.txt}} - presently implements auto-converting type hinting without any warning on data loss.
  
 ===== Changelog ===== ===== Changelog =====
   * restructured to provide 3 options (two with current type juggeling rules and E_STRICT or E_FATAL on data loss conversion and one with new type juggeling rules and E_STRICT on data loss.   * restructured to provide 3 options (two with current type juggeling rules and E_STRICT or E_FATAL on data loss conversion and one with new type juggeling rules and E_STRICT on data loss.
rfc/typecheckingstrictandweak.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1