On 05/02/15 11:37, Andrea Faulds wrote: > 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.
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
