Hi Stas, On Thu, Apr 30, 2015 at 8:24 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> > The objective to have type "hint" is to remove such checks by users, > > isn't it? > > No, not really. The objective is to ensure type of the parameter. If you > checks are not limited to types, then typing is not going to help, and I > don't think inventing special built-in type for each narrow use case is > a good way to go. > If you need to force to map value to PHP type, you have "strict" mode. "Weak" mode is just too strict currently even if PHP handled int/float/string as "integer"/"float" including invalid values traditionally. New PHP7 type hint doesn't allow "valid" int/float/string as "integer"/"float". This is unintuitive change for most PHP users because of weakly typed tradition. I'm sure there will be so many codes that misuses type hint if there is no "numeric" type hint. > > > Do you really think all users will write such code for database/json/etc > > values? > > No, I don't think all users need such checks. But those that do will > have to write the code for it. > Users must validate all inputs that cannot be trusted. e.g. Users must validate is JSON numeric value has numeric form expected. I think most users will just use type "hint" because users assumes it's a "hint", not type enforcement, and it works well for small values. > The issue is that weak mode type hint is *not* weak at all. It forces to > > have > > machine native type rather than it's data form. > > PHP types are not machine native types. But yes, it forces PHP type - > that's why it is *type* check. > Type hint is better to stay as "hint" under weak mode. IMO. > > > PHP apps are easily broken by too large value because PHP stops execution > > by fatal error. i.e. DoS became easy. I will never write such code, but > > That is a different issue. If you don't want fatal error, a) we have > proposal to make those exceptions, b) it is not fixed by introducing > pseudo-types for narrow use cases, since it is a completely different > issue. > It's alternatives. Resuming execution with exception is harder. Customizable pseudo-type is too late for PHP 7.0. We do decided to introduce basic type hint and it has issue to be resolved. Let's concentrate on resolution. > > > I don't > > want to check and fix library that I would like to use. I don't think I > > can manage > > programmers to do that even if they are under my control. > > You are saying type checking which produces fatal errors does not match > your use case. OK, I can sympathize, but how introducing more > pseudo-types helps? You just fix one narrow use case that you have right > now while leaving the problem still in the same place. That's not a good > way to address it. I'm not concerning myself, but I'm worrying about users to write apps/libraries that can cause DoS easily. I don't want to see my my apps emit fatal error by upgrading library just because library author decided to use type hint wrongly. Current type hint implementation/spec does not have protection/prevention at all. Having "numeric" type hint or StrictSTH RFC concept adoption are possible resolutions. If there is better resolution, I appreciate it. BTW, GMP integer is already integrated into PHP why not treat GMP as int? It's type "hint", isn't it? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
