Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84538 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21379 invoked from network); 11 Mar 2015 12:48:23 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Mar 2015 12:48:23 -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:48480] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B7/F1-07702-49930055 for ; Wed, 11 Mar 2015 07:48:21 -0500 Received: (qmail 3806 invoked by uid 89); 11 Mar 2015 12:48:17 -0000 Received: by simscan 1.3.1 ppid: 3795, pid: 3802, t: 0.1035s 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; 11 Mar 2015 12:48:17 -0000 Message-ID: <55003990.3030001@lsces.co.uk> Date: Wed, 11 Mar 2015 12:48:16 +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: <54F83C4D.1020206@gmail.com> <54F8BF67.6080600@gmail.com> <848D3C19-DE29-4E5F-9B23-D87D3F4A9365@gmail.com> <54FB45D6.3040803@gmail.com> <54FCD063.4040300@gmail.com> <54FEB910.5000608@lsces.co.uk> <54FF5E39.7000507@lsces.co.uk> <550035F0.10703@gmail.com> In-Reply-To: <550035F0.10703@gmail.com> 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 11/03/15 12:32, Rowan Collins wrote: > Lester Caine wrote on 10/03/2015 21:12: >> On 10/03/15 20:44, Yasuo Ohgaki wrote: >>>>> YES there is room to create a more consistent procedural interface, >>>>> but >>>>> my original question still applies "consistent with what rules?" >>> It's possible choice. >>> I agree that names without "_" looks more consistent. >>> Personally, I don't care much about having "_" or not for procedural >>> API. My >>> only concern is naming consistency. >>> >>> Names without "_" changes basic coding rule. >>> Problem is how to make a choice and how to define exceptions. e.g. >>> nl_langinfo() >>> >>> I wonder how many of us prefer names without "_". >> The one thing that your RFC demonstrates perfectly is just how much has >> to change to match that rule. Change the rule and the number of names >> that need alternatives is considerably less. I know a case was made at >> the time for adding underscores to the guidelines but it's quite clear >> that this was the mistake? > > PHP function names are case insensitive, and conventionally written in > lower-case (a convention that nothing decided on this list will change), > so underscores are important for readability. > > To take an example Yasuo has mentioned a couple of times, pg_lo_open() > without any underscores at all would be pgloopen(), which is very hard > to read: it could be pGloopen(), pgLoopEn(), pGlooPen(), pgLoOpen(), etc. > > For whatever reason, PHP's users decided to go with camelCase > identifiers for methods, rather than underscores. I don't think that was > a decision that originated in the core distribution (which for a long > time had very few object APIs), and I don't think it's one that can be > changed by the core distribution (or, at this stage, anyone). > > If PHP had had namespaces from day 1, and camel-case conventions, it > would have been pg\loOpen(), but we can't change history. But that is exactly what this RFC is trying to do? The answer to this question is important right across the board, and the consistency problem only comes about because of historic decisions. The shear volume of changes proposed in the RFC is only appropriate in one name space, and potentially makes what are CURRENTLY more compatible names with the OO style more incompatible. What is needed is a comprehensive solution to naming in general including all name spaces, and while camelCase is not documented for the core, it is USED in a lot of existing extensions. NEW extensions would probably follow that format, so why not make namespace and OO styles follow that and maintain the existing legacy space following the underlying IEEE standards? -- 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