Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81899
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <54D34CD6.6020401@lsces.co.uk>
Date: Thu, 5 Feb 2015 11:37:02 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <585A6531-BFF1-4B40-9052-518518A9409F@ajf.me>
References: <54D34CD6.6020401@lsces.co.uk>
To: Lester Caine <lester@lsces.co.uk>
Subject: Re: [PHP-DEV] hints and constraints
From: ajf@ajf.me (Andrea Faulds)

Hi Lester,

> On 5 Feb 2015, at 10:58, Lester Caine <lester@lsces.co.uk> wrote:
>=20
> Can I please rename the 'big integer' rfc to 'unconstrained integer' =
for
> two reasons. One BIGINT does have well established definitions in the
> last 10+ years of PHP and other code bases.

This is not true. The terms =E2=80=98arbitrary-precision integer=E2=80=99,=
 =E2=80=98bignum=E2=80=99 and =E2=80=98bigint=E2=80=99 have quite =
well-defined meanings. Yes, =E2=80=9Cbigint=E2=80=9D is also used in SQL =
to mean a 64-bit integer, but SQL is the odd one out, and anyone who has =
read the RFC will understand that it is not the SQL kind we are talking =
about.

> Two - it more accurately
> defines the situation which then allows other discussions to be =
clearer.

The current description isn=E2=80=99t totally inaccurate, but I had =
considered renaming the RFC since =E2=80=9Cbig integer support=E2=80=9D =
implies we don=E2=80=99t already have support for big integers, though =
we do in the form of ext/gmp. A better title for the RFC might be =
=E2=80=9Cmake PHP integer type be arbitrary-precision=E2=80=9D. Still, =
it=E2=80=99s a minor issue at best.

> If the current 'constrained' integer is promoted to 'unconstrained', =
it
> introduces another layer of checking which up until now has not been
> necessary. Where the bulk of the code currently assumes an integer is
> 32bit, all of that code now needs to be reviewed to see what the =
effect
> of now passing an unconstrained integer will be.

That code is also broken on 64-bit platforms, and has been for a decade. =
Actually, longer: x86 wasn=E2=80=99t the first architecture to support =
64-bit, but it supporting it certainly increased the prominence of =
64-bit computing.

> There is a demand for 'strict' which to a certain extent I can
> understand, but if that is combined with an unconstrained integer
> definition, then a large section of the code base will need to be
> reworked to add back the natural checking that the 32bit constraint
> provides.

Again, there isn=E2=80=99t a 32-bit constraint, PHP only has an integer =
constraint. Actually, PHP has never had an integer type hint, so I =
don=E2=80=99t know what you mean by =E2=80=9Cadd back the natural =
checking=E2=80=9D - there was never any such check.

> If I am passing variables between functions, then I need to
> add some additional checks, but both of these moves add another level =
of
> complexity which is not 'constrained' by the core framework. If I want
> to 'hint' that a parameter is an integer then personally that is a =
32bit
> constrained value.

Only if you=E2=80=99re on a 32-bit system. PHP has had 64-bit integers =
for a long time now.

> Similarly 64bit is bigint and 16bit is smallint. If
> the only hint or strict check is 'unconstrained integer' then I see
> little value in even bothering with it, but if I can hint at 'integer'
> and know that any other database system is providing the same
> constrained integer then it has some purpose.

Hints have usefulness beyond that of typing SQL data. Actually, you =
really shouldn=E2=80=99t rely on PHP to ensure your integers fit =
database fields anyway. Databases offer 8-bit, 16-bit, 32-bit, 64-bit, =
sometimes even larger sizes. At any given time, PHP=E2=80=99s integer =
type is only going to correspond to one of those, or perhaps none of =
those. PHP isn=E2=80=99t obligated to provide you with types for =
multiple integer sizes. It=E2=80=99s a dynamic language that doesn=E2=80=99=
t need such things, it only needs one size of integer. PHP is designed =
for rapid development of applications and for ease of use, not for =
ultra-high performance. If you want to ensure an integer fits in a =
database column, that is your, or the database=E2=80=99s, =
responsibility.

> While it would be nice simply to ignore any limit, in practice we have =
a
> well defined set of limits,

No, those limits are only as well-defined as the platform makes them. If =
I really want to, I can create a 17-bit virtual machine and compile PHP =
for it and have 34-bit integers, and PHP will probably work on it.

> which currently PHP does not respect as well
> as it should do.

PHP perfectly respects the constraints of a platform=E2=80=99s native =
integer size. It need not do anything more.

> I would be a little happier to accept hints and
> constraints that had a practical use, but I don't see any of the =
current
> proposals providing a useful endpoint, only asking us to create even
> more code to restore clean operation of legacy code!

Type hints are not only useful for checking if bad stuff gets in your =
database. Actually, relying on them to do that is almost certainly an =
abuse of type hints. You need to validate your data before it goes in =
the database - you have always had to do this, and it is merely a happy =
coincidence that you could get away with not validating integer ranges =
in some cases.

> At the very least, some means of providing a central 'constraint' =
method
> which can be switched on in much the way that 'strict' is currently
> being proposed, but I don't feel that is 'the PHP way' and some of the
> flexibility PHP currently provides is actually constrined in a much =
more
> practical manor than the current proposals.

I hardly see the need for constraints in this case: we=E2=80=99ve had =
if() and throw for ages now, and they do this specific job perfectly =
well.
--
Andrea Faulds
http://ajf.me/