Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84188 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93062 invoked from network); 2 Mar 2015 21:40:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Mar 2015 21:40:17 -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.192.45 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.192.45 mail-qg0-f45.google.com Received: from [209.85.192.45] ([209.85.192.45:42361] helo=mail-qg0-f45.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F3/ED-14834-FB8D4F45 for ; Mon, 02 Mar 2015 16:40:16 -0500 Received: by mail-qg0-f45.google.com with SMTP id z107so7440206qgd.4 for ; Mon, 02 Mar 2015 13:40:12 -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=p4+PCU1ncBiiAM0etYdIwk0zHJT9PwugoI6o67s45ys=; b=PX0PuvnK4VmV8DSG9yP4T4MFa+jyfsawXpEgyhtEhI7nHOn3JGntZbCOWF5p0zfS6p SLT7yywMNebpMmVyVrDMLWMGJQ6rZT5S8n4bodnEtoOCqShNKEz+dqksRLa1GyXfQ04e aFZOsUD2T8ocz2EADjHUtQI69j2qSKWdH+8IaQhFkfjWYU6+VsrLdk2Io+m5MAkLWQlr 880aGC/Q85/33P11x2+3x9DQWNGz/SMnsfsC5khx5euHVNh8nsYS+7nMJYZ/6EzeHJT6 F7vnwjxd6ppzp7JGeHrPEcCXf0sgxTdq6Ca6pyln7n8bx83r+9+gBMsAhP6mMDCeTtcT Mylg== X-Received: by 10.229.95.74 with SMTP id c10mr47407192qcn.17.1425332412788; Mon, 02 Mar 2015 13:40:12 -0800 (PST) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.229.198.8 with HTTP; Mon, 2 Mar 2015 13:39:32 -0800 (PST) In-Reply-To: <54F4159A.6010903@fischer.name> References: <5E7DF0C5-BCB4-432A-A876-A5057FEBFBB5@gmail.com> <54F320E9.5000706@fischer.name> <54F4159A.6010903@fischer.name> Date: Tue, 3 Mar 2015 06:39:32 +0900 X-Google-Sender-Auth: pPPs67rejee1rBPrbCPEObMHK2E Message-ID: To: Markus Fischer Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a11344c8626b5cf0510551033 Subject: Re: [PHP-DEV] Consistent function names From: yohgaki@ohgaki.net (Yasuo Ohgaki) --001a11344c8626b5cf0510551033 Content-Type: text/plain; charset=UTF-8 Hi Markus, On Mon, Mar 2, 2015 at 4:47 PM, Markus Fischer wrote: > On 01.03.15 21:19, Yasuo Ohgaki wrote: > >>> The answer is no, it's just not worth it. Having a function called > >> str_pos which is an alias of strpos, but only on some versions, is more > >> confusing, not less. > >> > >> My sentiment too. Factor in that someone already using the proposed > >> himself, things can only go south from here. > >> > >> If PHP wants to clean up, then do it right: use a namespace for it. > > > > > > I agree use of namespace is better solution. It's rather severe BC, > though. > > How about rename functions except "string" and "array" related functions > ? > > > > BTW, I cannot change document system, but I'm going to update all doc > > contents if this passes. > > I'm not sure we're on the same page. I'm talking about moving in > "no-BC-break" way, if at all. That is, no existing function be touched. > I would love to have namespace that could be imported like namespace \php\7\function\* as \; // Import all functions to \ namespace \php\7\function\* as \; and have INI like default_namespaces "\php\7\function\* \php\5\function\*" This way, we'll have no-BC since user can select functions to import. (Namespace layout should be improved. Above example will have issues most certainly) Your idea is similar to this, I guess. > > As to whether namespaces-aliases are really necessary I leave for others. > > I think a sensible thing to do at this stage would be, rather than > changing existing stuff, laying the ground work how to do it in the > future. What I mean is: an RFC for consistent introducing new "names" in > the PHP language. > > So that /future/ functionality does not always get slapped into the > global namespace but that we finally start using our reserved PHP\ > namespace and put stuff in there instead of the global pollution. > > Yeah, I think that direction is a sensible start and gather peoples > mindset about this instead of going backwards, renaming stuff without > clear plan, etc. We may postpone some renames. I wrote almost complete list. Please take a look at https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed There are many functions that can have aliases safely. I'll post [RFC][DISCUSSION] now. Please comment on new thread! Thank you. -- Yasuo Ohgaki yohgaki@ohgaki.net --001a11344c8626b5cf0510551033--