Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61500
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50083782.7010403@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>
Date: Thu, 19 Jul 2012 18:04:27 +0100
Message-ID: <CAN+gjScEKrX9pkK2OU5OeqDR13Z5RThLfO8Pdvh9rUOHGTtecg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e0cb4e6ffbf7b8569504c531c578
Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
From: ajfweb@googlemail.com (Andrew Faulds)

--e0cb4e6ffbf7b8569504c531c578
Content-Type: text/plain; charset=UTF-8

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.
On Jul 19, 2012 5:36 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!
>
> --
> 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
>
>

--e0cb4e6ffbf7b8569504c531c578--