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" <[email protected]> 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
>
>