. most of the functions are procedural and string/array/scalar
related. I would prefer to think about alternative solutions like the
NIkic's proposal using OO-like APIs. Keeps BC, brings cleaner APIs
into the game
I agree it's nicer.
My only concern is that the same discussion was done about 10 years
ago and still don't have them. We may be able to clean up string/array
functions. However it seems odds are high that we still have live legacy
names around next 10 years or more especially in modules..
I think what is missing here is simply an identification on what names people think need changing? Certainly creating an alternative set of objects and leaving the 'non-OO' baggage alone would be a lot more practical longer term? The problem will be that some people will want a means of turning off the legacy stuff and I am not sure that is really practical? e_strict currently seems to be a millstone rather than a help, and unravelling the impact of that is something that is key to PHP6 even before looking at moving things forward.