Hi Stas, On Thu, Apr 30, 2015 at 9:20 AM, Stanislav Malyshev <smalys...@gmail.com> wrote:
> > 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. > > That is what was decided by votes - to make type conversions fail on > values that can not be represented by these types. > How many of us are expected that mydb_find_by_id(INT_MAX+1); Note: INT_MAX+1 is pseudo integer string value. fails with fatal error? I guess it's not many. (This is one of the main reason why I strongly supported CoerciveSTH RFC. Sorry, I wrote "Strict" where I should write "Coercive". It was confusing.) The max is only about 2 billions under 32 bit platforms. Please don't think only for servers, there will be number of IoT devices that can use PHP to control it. > New PHP7 type hint doesn't allow "valid" int/float/string as > > "integer"/"float". > > Because "string having lots of digits" and "integer" is not the same > thing - the latter has limits, the former does not. You can not really > use them interchangeably. > It's fine to enforce specific type under strict mode. I guess basic design of current scalar type hint is to switch weak and strict mode interchangeably. That's the reason why I proposed "numeric" type hint here rather than CoerciveSTH RFC like behavior even if I prefer it. > This is unintuitive change for most PHP users because of weakly typed > > tradition. > > I don't think it's correct - there was never tradition that any string > can be successfully represented in integer type. It's just not possible > - integer type is a limited type and string is not. The only change was > made that if it can not be represented, the parameter typing produces > failure. I'm not a big fan of it, but that's what the vote decided, so > that's what we have. > Users are recognized record ID as integer even if it's a string integer indeed. I think many, if not most, users are not aware that db record ID field is "string integer" . As long as users do not apply arithmetic, string integer worked perfectly with PHP. I'm saying this is a tradition. > I'm sure there will be so many codes that misuses type hint if there is no > > "numeric" type hint. > > I'm also sure their problem is not in absence of type that says "string > matching regexp [0-9]+" since I do not see a use case which such type > would improve. You can not do anything you do with int with such type, > and if you need to so string pattern validation, that's not function of > the type system, at least not in PHP. > Most obvious use case is record ID that I mentioned above, but it's not limited to record ID. e.g. all database numeric values/JSON numeric/ PHP array integer type key beyond INT_MAX/MIN. > > > Users must validate all inputs that cannot be trusted. e.g. Users must > > validate is JSON numeric value has numeric form expected. > > Surely, but we won't have scalar types of "url", "email address", "host > name", "IPv6 IP address", "phone number in Brazil" or "russian car > license plate" - even though I'm sure validating such strings has a lot > of applications. It's just not what types in PHP do. Of course, you can > have *user* types implementing all that - nothing prevents you from > doing it. > String can represent any values so users must be careful, but not int and float. The reason why strictly typed languages are safer, is "int" is int always. I don't think strict typed language automatically safer than PHP as many strictly typed language's web frameworks work seamlessly for types, but it's safer actually because "integer like value" is int almost always. > 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. > > I'm not sure I understand what you mean here. > Great. I think "int"/"float" type hint is too strict even under weak mode. Therefore, I want to have "numeric" type hint at least. > 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. > > That's what we're doing, and the resolution should not be introducing > ad-hoc pseudo-types for specific use cases. For 7.0, the resolution can > not be introducing anything at all, as April 29 > March 15, but more > long-term it is also not the right approach. > > > Having "numeric" type hint or CoerciveSTH RFC concept adoption are > > possible resolutions. If there is better resolution, I appreciate it. > > I don't see what specifically you're trying to resolve. If the case is > to validate numeric strings, there are functions for it. If the case is > to avoid failures on dirty data, your only option is pre-validation, > since strict validation is what was decided for parameter types. If > you'd like to change that, you can submit an RFC for 7.1, but as it was > just recently decided by vote otherwise, I don't see how such RFC can > succeed. > Having "numeric" or accepting huge value(including GMP) for "int"/"float" should be acceptable. IMHO. As I wrote, huge numbers are valid data for databases. I don't want to have DoS incident just because PHP limits numbers to native type range while databases accept these larger values as valid values. > > > BTW, GMP integer is already integrated into PHP why not treat GMP as int? > > Because GMP object is not int. It can be convertable to int, but the > question of conversion failure still remains. > I think it's OK to fail when "strict" mode is enabled. > > > It's type "hint", isn't it? > > I'm not sure I understand what you mean here. We may have integrated GMP float in near future also. Accepting compatible value/type is mandatory if it's a type "hint" for weak mode. I don't think we decided to have type declaration(type enforcement), do we? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
