Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86206
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <55518D59.6070108@gmail.com>
References: <CAGa2bXaFnkU7hqR56kGkWqbrc8KivGEjUCXLi=5cJ5wr7MCq4Q@mail.gmail.com>
 <55518D59.6070108@gmail.com>
Date: Thu, 14 May 2015 14:19:17 +0900
Message-ID: <CAGa2bXYANJ4hN2c6zwr4wdbBn2zbOMfwzj9Pz8+Srm8Djr3P9Q@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d1dc6f294ee051603e04a
Subject: Re: [PHP-DEV] is_digits() and digits type
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113d1dc6f294ee051603e04a
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Tue, May 12, 2015 at 2:19 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> >  - is_digits() and digits type for digits only inputs(integer like
> string)
> >  - is_numeric() and numeric type for float like string
>
> This is not what types are in PHP, and not what they should be, IMO. If
> you want to assign arbitrary checks to a variable, I would suggest using
> a class with a suitable constructor. If you think it's too slow (meaning
> you are doing very heavy in-memory data processing and nothing else),
> make an extension - it would be roughly the same speed as native PHP
> types. If you want it to be extensible - then you may be looking for
> something like pre/post conditions and DbC, but this is another story
> for which we need proper RFCs, etc.
>

I agree that validation and DbC is far better than resolution I proposed
here.
I guess DbC will not prevent users from abusing type hints, though.



> However, calling random combination of native types, objects and string
> constraints "type" because somewhere there's use case for it does not
> look like a good design for a language. It's too random and ad-hoc.


If we aren't going to change any, we need large warning in the manual,
explain nature of external data, compatibility issues between 32 bit and
64 bit CPU, what kind of data is appropriate for native type hints, etc.
It's not a difficult job to do.

How about have functions check if value fits to certain data types,
32 bit int, 64 bit int and IEEE double?

We may add/extend is_digits()/is_numeric() for this. It would be handy
for DbC also.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113d1dc6f294ee051603e04a--