Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61502
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5008429D.8000605@lsces.co.uk>
References: <CAN+gjSe7r2SoRNYufcaB2ktK05shH1AcAsaFSbUibF9r4TeRrw@mail.gmail.com>
	<op.whkdiodaidpuyk@damnation>
	<CAEZPtU5Rb9W8iydy2-hoYqGDSWqd9WCTUXh214O-uCc3nVNiVA@mail.gmail.com>
	<50059AF8.5050805@sugarcrm.com>
	<CAEZPtU4hQ5GjMZ2b6T5d1_dTp01r7_rg8613JZ_5AuBVc29B7w@mail.gmail.com>
	<5005CB58.2020601@sugarcrm.com>
	<CAEZPtU6as2QKQKfp6cCrW=Xjq9v3ZW1u+jbNJBT0DfDQoa8CdA@mail.gmail.com>
	<50066724.6050901@sugarcrm.com>
	<CAEZPtU6hK8rZFA+QLT4vPch+QdZ9r4FgBsJAVcpaBWW7VFA1ow@mail.gmail.com>
	<50070538.10206@lerdorf.com>
	<CAEZPtU61tisNvefTCa4viMhyvjGAFLyjmf7ya953AW4oGmEtxw@mail.gmail.com>
	<50082C7E.4080400@lerdorf.com>
	<CAEZPtU5zzxN4ihbC1OtPU-suCAOJQaftMefW9+9rto=FE3hoHg@mail.gmail.com>
	<50083782.7010403@lsces.co.uk>
	<CAN+gjScEKrX9pkK2OU5OeqDR13Z5RThLfO8Pdvh9rUOHGTtecg@mail.gmail.com>
	<5008429D.8000605@lsces.co.uk>
Date: Thu, 19 Jul 2012 18:35:31 +0100
Message-ID: <CAN+gjScKbwU4jvphz=nh1tOccU5bb=h2wSLvKfANSOpOKSWsog@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04448135c751a204c5323441
Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
From: ajfweb@googlemail.com (Andrew Faulds)

--f46d04448135c751a204c5323441
Content-Type: text/plain; charset=UTF-8

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" <lester@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
>
>

--f46d04448135c751a204c5323441--