Hi Lester, > On 5 Feb 2015, at 10:58, Lester Caine <les...@lsces.co.uk> wrote: > > 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. > 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. > 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. > 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. > 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. > 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. > 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’s 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’ve had if() and throw for ages now, and they do this specific job perfectly well. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
