Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85359 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19441 invoked from network); 21 Mar 2015 11:13:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Mar 2015 11:13:35 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:40273] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 93/00-18917-C525D055 for ; Sat, 21 Mar 2015 06:13:33 -0500 Received: (qmail 19439 invoked by uid 89); 21 Mar 2015 11:13:30 -0000 Received: by simscan 1.3.1 ppid: 19432, pid: 19435, t: 0.0771s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@109.156.131.40) by mail4.serversure.net with ESMTPA; 21 Mar 2015 11:13:30 -0000 Message-ID: <550D5259.5040203@lsces.co.uk> Date: Sat, 21 Mar 2015 11:13:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: =?UTF-8?B?UmU6IFtQSFAtREVWXSBUZW4geWVhcnMgZXN0aW1hdGVkIFBsYW4gdG8=?= =?UTF-8?B?IHJlcGxhY2UgUEhQ4oCZcyBpbmNvbnNpc3RlbnQgQVBJ?= From: lester@lsces.co.uk (Lester Caine) On 21/03/15 04:01, Nathan wesley wrote: > The old API should be deprecated in PHP 8.0 and removed completely in PHP > 9.0 (finally) WHY? You don't HAVE to use the current API and wiping out all of the legacy code does not seem like a 'gain'. The two can co exist. > I hope that you take this seriously and tell me if there are any > limitations that prevents this from happening. I am currently working through a review of options to add one of those pop-up chat functions to my framework. There are several designs available, the majority of which as usual are charged for services, but once one culls those from the search results one gets back to a few where the code is ACTUALLY available open source. The problem however is that many of these libraries are now being written to 'modern standards' and this results in their being LESS reusable since the coding style makes them incompatible even with one another. I have managed to find ONE option which looks like it may be portable enough to convert to an installable package to work with the rest of my framework. Just have to convert every file from a single line of code back to something with a real layout so I can use it. A 120000 character long line works with PHP, but is just as unreadable as some of the new coding styles! YES some old code needs culling ... but equally there is just as much bad new code. Both have their place. Mind you in 10 years time I'll probably be dead and some one else will have to re-write the entire code base :) -- 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