Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84282 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49538 invoked from network); 4 Mar 2015 09:05:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Mar 2015 09:05:32 -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:33183] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/00-49216-BDAC6F45 for ; Wed, 04 Mar 2015 04:05:32 -0500 Received: (qmail 3508 invoked by uid 89); 4 Mar 2015 08:58:40 -0000 Received: by simscan 1.3.1 ppid: 3431, pid: 3479, t: 4.6061s 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; 4 Mar 2015 08:58:35 -0000 Message-ID: <54F6C936.9080406@lsces.co.uk> Date: Wed, 04 Mar 2015 08:58:30 +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> <554F0C3F-770F-4694-A5AB-FDC54FCCBF00@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 04/03/15 03:34, Yasuo Ohgaki wrote: > I made list of rename candidates > https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed > If you have suggestions, I appreciate! Taking the starting point ... the coding standard for writing C code for PHP ... personally I would love if the PHP code area followed all of the rules in the C set. My own particular grip is with using tabs internally in the C code, but spaces in the PHP code. The very reason that PSR is another inconsistency. So we follow C rules for C code and PSR rules for PHP. Or not ... I will always use tabs across all code bases, but the other point here is that PSR demands camelCase rather than adding underscores and many of the new libraries have been added following that format rather than the C rules. So even replacing the whole structure of internal names, they will be inconsistent with external naming 'rules'. The coding standards themselves are inconsistent :( If we are looking at the C codespace, then as has already been said we are using C library names in a large majority of cases. So programmers who are switching between C and PHP codespace either need to rebuild all of the C libraries using the new names, or live with that inconsistency? I am slowly coming around to the thought that since how I would prefer to work is not going to be provided by PHP then creating my own versions of some extensions is going to be the right way forward, so I will perhaps be working more in 'C' space than in 'PHP' space. This is partly because of the growing uncertainty about handling SQL compliant types in PHP, and the increasing need to work out how to add back the limit checks provided naturally by 32bit processor builds. There are a lot more important things than introducing what I view as yet another layer of inconsistency when for example, the whole string management area needs to be augmented with a proper object based structure where the str_ becomes redundant? mbstring should also become redundant in that rework. As I have already said, the GD library is just a wrapper around the underlying libgd C package, and while it is now maintained by Pierre under the umbrella of PHP, it is used in other languages so creating a new wrapper for PHP without regard for it's C and other interfaces is again introducing more inconsistencies. While http has been rejected for bundling, it is another example of not following the C coding standard ... -- 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