Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:61501 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 8933 invoked from network); 19 Jul 2012 17:23:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jul 2012 17:23:48 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.131 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 213.123.20.131 c2bthomr13.btconnect.com Received: from [213.123.20.131] ([213.123.20.131:9189] helo=mail.btconnect.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8D/E4-18983-1A248005 for ; Thu, 19 Jul 2012 13:23:45 -0400 Received: from host81-138-11-136.in-addr.btopenworld.com (EHLO _10.0.0.5_) ([81.138.11.136]) by c2bthomr13.btconnect.com with ESMTP id IJH89576; Thu, 19 Jul 2012 18:23:41 +0100 (BST) Message-ID: <5008429D.8000605@lsces.co.uk> Date: Thu, 19 Jul 2012 18:23:41 +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: PHP internals References: <50059AF8.5050805@sugarcrm.com> <5005CB58.2020601@sugarcrm.com> <50066724.6050901@sugarcrm.com> <50070538.10206@lerdorf.com> <50082C7E.4080400@lerdorf.com> <50083782.7010403@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.5008429D.0032, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.7.19.163315:17:7.944, ip=81.138.11.136, rules=__MOZILLA_MSGID, __HAS_MSGID, __SANE_MSGID, __HAS_FROM, __USER_AGENT, __MIME_VERSION, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __CT, __CT_TEXT_PLAIN, __CTE, __ANY_URI, __URI_NO_MAILTO, __URI_NO_WWW, __CP_URI_IN_BODY, BODY_ENDS_IN_URL, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.5008429D.01B4:SCFSTAT14830815,ss=1,re=-4.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false 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! 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 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