Been tied up with a family matter for the last couple of days, so I've not been able to read all 200 posts in my in box for internals.
Whilst I've been away from the computer I've had time to contemplate, and I think we need to summarise the discussions in a different way. A number of disjointed threads currently exist, which are actually more closely related! When PHP5 was evolving, the majority of systems were still 32bit constrained, although 64bit hardware was well established. At that time an 'integer' was also constrained to 32bit. The evolution to 64bit has again in hindsight not been well handled and currently promoting an integer to float to gain access to a 64 bit integer has a number of black holes, so care has to be taken NOT to allow that when dealing with a BIGINT value. The development of 64bit builds has now muddied the water further as a check has to be made as to just what the constraints are on an integer before progressing. Code written for a 64bit build may not work as expected on a 32bit one, and it was this black hole I was originally trying to address. 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. Two - it more accurately defines the situation which then allows other discussions to be clearer. 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. 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. 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. 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. While it would be nice simply to ignore any limit, in practice we have a well defined set of limits, which currently PHP does not respect as well as it should do. 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! 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. -- 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
