wat The pseudo- prefix means something. These scalar and array vars are unchanged. The methods are implemented via an engine shortcut, not by making them objects. On Jul 19, 2012 6:24 PM, "Lester Caine" <les...@lsces.co.uk> wrote:
> Pierre Joye wrote: >> >> should still work. All the string API methods need to be >> available on >> >every pseudo-object regardless of the type. So I don't see >> any >> "cleanup" >> >here either. >> >> I do, and again this is purely a theoretical discussion right now. >> However I find disturbing the resistance to such a proposal given >> that >> what I hear from our users is a total support to introduce this >> concept to PHP, even step by step. >> >> So we should better begin to see where are the technical >> bottlenecks >> and figure out a way to solve them instead of arguing about >> whether we >> should do it or not. Because we will have to do it, whether we >> like it >> or not. >> >> >> So a few people want this therefore we all have to have it? >> We need to sort out a list of priorities and then perhaps see if >> there is a >> majority demand for each? >> >> Since somebody will obviously rewrite key libraries using this 'sexy' >> stuff, >> we are all then forced to have to work with it even if we can ignore >> it in >> our own code. ONE of these days I'd like to get back to putting some >> new >> functions in my own code base. I'm still working on a long list of >> 'strict' >> warnings across several projects and libraries :( Work that I don't >> make any >> money from but am having to do simply to keep things simple when the >> NEXT >> changes happen! >> > > Andrew Faulds wrote:> PHP is all about backwards compatibility. > > > > We only break things that need to be broken. The legacy > > str*/str_*/string_*/array_* functions will still work. > > You are still missing the point here. > > That the old stuff still works most of the time would be nice if one could > rely on old code STILL working several versions later. The problem comes > when someone 'updates' a key library to new stuff that does not then play a > well with the legacy stuff. So we have to manage which versions of > libraries are compatible, and as in the case of security problems manage > our own backport of fixes to keep compatible versions save. I'm having to > update the 'strict' compliance simply to keep in line with libraries that > have also 'been updated' just to keep standing still. > > In the case of this new style of writing string and array stuff, they have > to play transparently with the legacy variables when a library is used in a > legacy project. So what is the point of yet another method of doing the > same thing we have been doing happily for years? If you must have array and > string object, just add an optional extension and then we can make sure it > never gets used for library projects :) > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - > http://lsces.co.uk/wiki/?page=**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<http://rainbowdigitalmedia.co.uk> > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
