Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86053
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <5541753D.5050908@gmail.com>
References: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com>
 <55401F31.9030703@gmail.com> <CAObuZduZBM0GyWJMA1Fd7eCgPE4vFFZrrhpREQ50a4QJhG6Nvg@mail.gmail.com>
 <CAGa2bXar_oXrsPAErNx5BUdkFAy-p8-D0tfhc3pAnDTGBGJJ7Q@mail.gmail.com>
 <55416849.9010808@gmail.com> <CAGa2bXbkCx2Nqb9YBut3id4N=nhjLBGPN8Ucrx7R6mRnGjB2og@mail.gmail.com>
 <5541753D.5050908@gmail.com>
Date: Thu, 30 Apr 2015 10:15:50 +0900
Message-ID: <CAGa2bXYk=2TVFv9aeDjVRpgLKFjhYx6YBCpmWo10u-Qv8b0zpg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Ryan Pallas <derokorian@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c306f08c117c0514e6d8d2
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c306f08c117c0514e6d8d2
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Thu, Apr 30, 2015 at 9:20 AM, Stanislav Malyshev <smalyshev@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
yohgaki@ohgaki.net

--001a11c306f08c117c0514e6d8d2--