Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61499
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.188 cause and error)
Message-ID: <50083782.7010403@lsces.co.uk>
Date: Thu, 19 Jul 2012 17:36:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
MIME-Version: 1.0
To: internals <internals@lists.php.net>
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>
In-Reply-To: <CAEZPtU5zzxN4ihbC1OtPU-suCAOJQaftMefW9+9rto=FE3hoHg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Pseudo-objects (methods on arrays, strings, etc.)
From: lester@lsces.co.uk (Lester Caine)

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
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