Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84264 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89278 invoked from network); 3 Mar 2015 20:08:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Mar 2015 20:08:50 -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 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:34663] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 57/20-22264-1D416F45 for ; Tue, 03 Mar 2015 15:08:50 -0500 Received: (qmail 2383 invoked by uid 89); 3 Mar 2015 20:08:46 -0000 Received: by simscan 1.3.1 ppid: 2357, pid: 2380, t: 0.0848s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.189.147.37) by mail4.serversure.net with ESMTPA; 3 Mar 2015 20:08:45 -0000 Message-ID: <54F614CD.6060208@lsces.co.uk> Date: Tue, 03 Mar 2015 20:08:45 +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: <54F4E29D.7080501@garfieldtech.com> <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com> <54F4F3FC.6060501@fischer.name> <54F4FDFB.8010701@lsces.co.uk> <54F5895D.3090002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Consistent function names From: lester@lsces.co.uk (Lester Caine) On 03/03/15 18:54, Yasuo Ohgaki wrote: > More or less, we do need maintenance, otherwise phpversion() will remain > inconsistent forever. IMO. Is there any reason why a few peripheral functions like that can't simply remain as is? ADDING an object with what I will simply describe as 'the new style of coding' which provides an alternative API has to be the sensible way forward. An object for ini management with a more convenient display function in addition to the simple phpversion dump. > I fully understand your arguments/reasoning, but I fails to see why not > having aliases to have shiny procedural APIs for major version up... Changing the parameter order on the existing function set is not practical, but similarly so is changing names which will then produce an abysmal mess when searching help files especially when reliance on google to provide that function means that we have no control on just which version of names are looked up. The more I look at this from the other side, the better the idea of simply adding new format objects to augment the legacy function set looks. Certainly leaving things like gd alone and adding a parallel 'coding style complainant' extension also allows changes to the parameter order. Apply the same approach to some of the other extensions and at some point in the future we can drop legacy versions ... although I suspect that a legacy build will still have a place for some time to come. The piece of the jigsaw I am missing is at which point does it become better to create a new extension for a complex object rather than simply writing a set of PHP classes? -- 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