Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84314 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 63234 invoked from network); 5 Mar 2015 03:59:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Mar 2015 03:59:47 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.181 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.216.181 mail-qc0-f181.google.com Received: from [209.85.216.181] ([209.85.216.181:42039] helo=mail-qc0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7C/AF-56703-0B4D7F45 for ; Wed, 04 Mar 2015 22:59:45 -0500 Received: by qcwb13 with SMTP id b13so3488686qcw.9 for ; Wed, 04 Mar 2015 19:59:42 -0800 (PST) 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=8mCMYyB0tz7h80aAx7TY9NEkV0fmRYFAcBfBIfEBkdE=; b=f31hqar35iwHYY1B9UZe/8U9aVh8tMioRyhjM7AEH/Yjn2E8ZKUEwME+l2zptTG5U5 ydj+gkASPpZTqz+2lFbfG39P3H4x4C6btkIGtazCt3Myut+ukZfKOwwQkXkqiblmRlNW fx6B0L8k+ZV1/8Ixkm76Jzkxw0+6WdBACH/K07XXNyTLqHpoB8EvmYBslAjXrcfDDVY3 EKqG8pa++0CO7+EbYUgmCbbHNX1Ev53x7Z17md4nqPzj8jwFChLVfPWyidZiDlq4s0XW gfVnB+EE1E1oGa4p4GGuHoAqO5InzJOd4j78Rmd8aUbnlOegkKYHQksLLZ+enG25aUHs iA+A== X-Received: by 10.55.21.68 with SMTP id f65mr13938790qkh.47.1425527982342; Wed, 04 Mar 2015 19:59:42 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.198.8 with HTTP; Wed, 4 Mar 2015 19:59:00 -0800 (PST) In-Reply-To: <5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com> 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> <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com> <5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com> Date: Thu, 5 Mar 2015 12:59:00 +0900 X-Google-Sender-Auth: rlFUEQRKuQOXmf0tCWZDiklcj9s Message-ID: To: Rowan Collins Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a1147e752014a7605108299f8 Subject: Re: [PHP-DEV] Consistent function names From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a1147e752014a7605108299f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rowan, On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins wrote: > On 4 March 2015 21:27:53 GMT, Yasuo Ohgaki wrote: > >We cannot remove all issue at once. We are better to adopt incremental > >improvement, aren't we? > > I think this, more than anything else, is where I disagree (having been > persuaded by arguments in previous discussions). Incremental improvements > mean having the cost of change multiple times, and the benefit just a > promise for the future. It's like living in a building site while > rebuilding your house - sometimes necessary, but not what you'd choose. > > If we have two names with no other fixes now, then later a third name, or > some magic flag, which fixes the argument order and error behaviour, then > go through and tidy up, we'll end up with a whole flow chart of "if you > need to support version X, use Y; if you find a tutorial using A, replace > with B..." > > Some such change is inevitable - a huge number of tutorials became out of > date when ext/mysql was deprecated, for instance - but it's not something > to do "little and often" just to make things "a little bit better". Sounds reasonable. I've updated RFC to note not addressed inconsistencies explicitly. There may be others. Some of these may be addressed by this RFC. https://wiki.php.net/rfc/consistent_function_names#unaffected_php_functiona= lity ----------------- Unaffected PHP Functionality This RFC only addresses inconsistent names. These are the list of related inconsistencies. - Parameter order inconsistency. This may be addressed by =E2=80=9Cdefaul= t namespace=E2=80=9D in other RFC. - Return type inconsistency. Most severe inconsistency is =E2=80=9Cwrong = number of parameters returns NULL=E2=80=9D. This may be addressed by =E2=80=9CINI = switch=E2=80=9D in other RFC. - Constant name inconsistency. - Class and method names. Only =E2=80=9C__set_state()=E2=80=9D and =E2=80= =9Ccreate_sid()=E2=80=9D methods are addressed. Future Scope - Use of namespace to clean up global namespace at all. - New APIs that replace old APIs. - Parameter order inconsistency. - Return type inconsistency. - Constant name inconsistency. - Class inconsistency. ---------------- Functions return NULL for wrong number of parameters is easy one to fix without BC. We may have INI switch return FALSE for invalid number of parameters. return_value_consistency=3DOn/Off ; Returns FALSE when number of parameter is wrong for module functions. Parameter ordering issue may be addressed also. Instead of having alias, we may introduce new functions for them. The new function name could be issue, though. If you know good list of functions have strange parameter ordering, I appreciate it. Parameter ordering issue could be addressed by "default namespace" that can import functions/classes to root namespace. This approach requires more work, but it would be cleaner than simply having new API. I think this issue would be large enough to be a RFC, though... Do you have particular suggestions? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --001a1147e752014a7605108299f8--