Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84594 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41452 invoked from network); 11 Mar 2015 22:44:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Mar 2015 22:44:59 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.46 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.218.46 mail-oi0-f46.google.com Received: from [209.85.218.46] ([209.85.218.46:38347] helo=mail-oi0-f46.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 18/88-32765-A65C0055 for ; Wed, 11 Mar 2015 17:44:59 -0500 Received: by oiax69 with SMTP id x69so10792527oia.5 for ; Wed, 11 Mar 2015 15:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=56xhs/DwokpyGMUmCR1oFJVZsnlkPpbxXKR/CgOvYLM=; b=qklZvk3mtKtHCP07aogg7EK3nYP3XVaL8z+MTUdgqXQeYvAl58Hu25MjiL6fKnHrKI YYJWNT2nkMD2aHglbPc+f23fQDWeBDkSnGeGJIjOPHJbUx0mBapz/LsKjQGxAodIZ8M0 8YXueDYa1xlt71KafwISyrV3ln0LUL/pOou8dH+lFROUTXuYGEFQYKX700T14RoQiB07 O2ln1RIa5Eu0MUWr2SC8bfi5lGwu678pIdwZ0BGHAdqpc4gDhAHAqAfhK5KV8doXt0Sn oI3HtQwWvROYBpPjX5AuETiSJyShVj1gXj1YJ+wyIkwjFAwCrSrvsVMeq4osOFiqRXSz eaFg== X-Received: by 10.60.70.211 with SMTP id o19mr28560252oeu.21.1426113895467; Wed, 11 Mar 2015 15:44:55 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.202.58.2 with HTTP; Wed, 11 Mar 2015 15:44:15 -0700 (PDT) In-Reply-To: <550035F0.10703@gmail.com> 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> Date: Thu, 12 Mar 2015 07:44:15 +0900 X-Google-Sender-Auth: qp57yc5oML9ZmbwDYRLwR_stbs8 Message-ID: To: Rowan Collins Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a113334342610e405110b0445 Subject: Re: [PHP-DEV] Consistent function names From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a113334342610e405110b0445 Content-Type: text/plain; charset=UTF-8 Hi Rowan, On Wed, Mar 11, 2015 at 9:32 PM, 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. > We cannot change history, so we have to make choice that is feasible. I think use of "_" wasn't too bad. PHP stores function names as lower cased names. Therefore, error message says "Warning some error in imagecolorclosesthwb()", etc. It's hard to read, indeed. It also encourage users to use "imagecolorclosesthwb" as official name... It may be better to consider how namespace for internals should be used. Otherwise, we may have to rename functions/namespaces again in the future. It may be for PHP8. It may be for PHP7.x if changes are not destructive at all. Having namespace for internals would bring much flexibility for API changes, both OO and procedural API. I may try my best to have consensus. I think you also like to have OO style API for basic variables(int/float/array) as I am. Unless we have good/proper procedural API names, it would be an obstacle to have OO style API for basic variables. I wish you agree to do something for it. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a113334342610e405110b0445--