hints and constraints

Hi Lester,

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 ‘arbitrary-precision integer’, ‘bignum’ and ‘bigint’ have quite well-defined meanings. Yes, “bigint” 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.

All my C++ has smallint, int and bigint ... and has for years.

Two - it more accurately
defines the situation which then allows other discussions to be clearer.

The current description isn’t totally inaccurate, but I had considered renaming the RFC since “big integer support” implies we don’t already have support for big integers, though we do in the form of ext/gmp. A better title for the RFC might be “make PHP integer type be arbitrary-precision”. Still, it’s a minor issue at best.

Current integer variable has a constrained value. 64bit 'fixes' have
created a new set of rules to go with that. gmp support removes those
limits ...

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’t the first architecture to support 64-bit, but it supporting it certainly increased the prominence of 64-bit computing.

Broken in a way that was managable, but it is only in the last few years
that windows itself has become 64bit although 32bit builds are still
required in a number of marketplaces since 64bit ones don't work.
That the transition has not been handled well applies everywhere!

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’t a 32-bit constraint, PHP only has an integer constraint. Actually, PHP has never had an integer type hint, so I don’t know what you mean by “add back the natural checking” - there was never any such check.
CURRENTLY when an integer is too big it becomes a float.
Check for float used to flag up that the integer was bigger than 32 bit
because one was running a 32bit version of PHP but now flags up that
some extra checks are needed, but is_int identifies a constrained integer.

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’re on a 32-bit system. PHP has had 64-bit integers for a long time now.
See above.

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’t 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’s integer type is only going to correspond to one of those, or perhaps none of those. PHP isn’t obligated to provide you with types for multiple integer sizes. It’s a dynamic language that doesn’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’s, responsibility.
This is an area where PDO was supposed to help, but I still prefer
ADOdb's handling of this. That will need major work to make work with
your model of PHP7 :(
I would like to be able to handle the real world values safely in PHP
and MANY libraries other than just SQL ones require finite size integers.

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.
Standards provide for interoperability across many platforms. If a
standard found 17bit a sensible word size then it is a well defined limit.

which currently PHP does not respect as well
as it should do.
PHP perfectly respects the constraints of a platform’s native integer size. It need not do anything more.
BUT you are proposing breaking that constraint? Currently is_int
provides some level of constraint checking while you are proposing
removing that?

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.
THAT on one had is my reason for not being in the camp of 'we must have
well defined strict type of parameters in functions'. One of the main
design rules I follow is that values are only passed as parameters to
the database engine. This will produce an error in the engine if the
value is out of range ... The braces ... add checks on what is loaded
INTO the variable that will be sent and we have the belt ... currently
an is_int may be all that is necessary as the belt, but if I had a
suitable mechanism for 'smallint', '32bit int' and 'bigint' it is a
nicer belt.

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’ve had if() and throw for ages now, and they do this specific job perfectly well.
The action of if(!is_int()) does a specific job. All I am perhaps asking
for is is_smallint, is_32int and is_bigint so I know that other
programmers are working to the same rules as me. The fields returned by
PDO give the right data type rather than all being converted to
unconstrained integers. I think that this is perhaps why people are
asking for 'user defined' hints and constraints?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Lester Caine wrote on 05/02/2015 16:49:

The simple answer here is that there is not a 'single' definition of
integer ...
True. But the definition of "integer" in PHP is, and has been for many
years, "as big as this build can handle". With Andrea's patch, all
systems can handle really really big integers, which seems like a big
win to me.
Have no argument with the statement - but implementing it creates a need
for a BC compatible constrained integer.

I disagree. There is no consistently constrained integer in any recent
version of PHP, since it is build-dependent. The fact that all the
builds you routinely use are 32-bit gives you the illusion that this is
a standard constraint.

It's a bit like the difference between parsing the User-Agent of a
browser, and dynamically testing a particular feature - what is it you
actually need to know? If what you need to know is "is this integer
outside the range of a 32-bit signed int", then "if ( $foo >= pow(2,31)
)" is a more logical test than "if ( is_float($foo) )" anyway.

The only reason this would be a compatibility break is if code is using
the overflow-to-float (which you agree is undesirable) as a proxy
measure of the underlying platform type. If what you need to know is
genuinely "am I running on a 32-bit build of PHP", then what you need is
some functionality for probing that; perhaps PHP_INT_SIZE?

There may be an argument for introducing constrained integer types,
but doing so would be nothing to do with backwards compatibility.

Note that I am talking purely about the PHP userland here, not C
extensions. The extension API absolutely should have convenient
functions for range-checking ints of various sizes, be that 64-bit,
32-bit, 16-bit, or whatever; this is true whether or not userland
integers are made arbitrary-precision.

Regards,

Rowan Collins
[IMSoP]