Re: int64/size_t options votes clarification
Pierre Joye wrote:
In the case this RFC is rejected for 5.6, these options are really not
what is planed to do for 6.x as we should do it the clean way, as
explained in the various discussions here and as many of the
opposition used as argument as well.
See next ...
For those having voted no for 5.6 and the options, would you mind
explaining what are your wishes? It will help to move forward, no
matter the outcome of the votes.
Are you really saying that this is just a hack to get 5.6 working and that it will all require re-working in PHP6?
I'm not particularly bothered what you do with 5.6 myself and I'm sure a lot more 'users' are probably in the same boat. It will still be a few years before I've managed to get everything up to PHP5.4 and by then hopefully we will have PHP6 with a nice clean Unicode base ( which in itself I think requires dropping case insensitivity ) and a nice clean 32/64 bit operational switch. Yes there will still be a large number of 32bit only machines around so PHP6 will have to work transparently with them!
Basically I can't see any point wasting time on PHP5.6 at all. Except as a springboard to 'for 6.x as we should do it the clean way'! The usage figures show just how important the current builds are and I'm not seeing any reason to bother with 5.5 currently either ...
--
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
Thread (5 messages)