Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103970 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 42863 invoked from network); 1 Feb 2019 13:07:10 -0000 Received: from unknown (HELO es-i.jp) (180.42.98.130) by pb1.pair.com with SMTP; 1 Feb 2019 13:07:10 -0000 Received: (qmail 85219 invoked by uid 89); 1 Feb 2019 09:47:14 -0000 Received: from unknown (HELO mail-ot1-f44.google.com) (yohgaki@ohgaki.net@209.85.210.44) by 0 with ESMTPA; 1 Feb 2019 09:47:14 -0000 Received: by mail-ot1-f44.google.com with SMTP id i20so5521790otl.0 for ; Fri, 01 Feb 2019 01:47:14 -0800 (PST) X-Gm-Message-State: AJcUukeNPplgjNjcma3PoBIezZQmlj/q48gtmWK/ZXqppl8sUXM1y3ax kQJ3pZB5mTapTo/eygIfv0/XohFaFLCRdivMIQ== X-Google-Smtp-Source: ALg8bN7gE8J7uEj4k7gsz2z3OWxYDfjjcG7sGOaqnHV/5381Ov5F7JKLNBSpfYml6BeEfcxwW0FtffrurjVVowqBD3k= X-Received: by 2002:a9d:6191:: with SMTP id g17mr28903684otk.56.1549014428655; Fri, 01 Feb 2019 01:47:08 -0800 (PST) MIME-Version: 1.0 References: <0243D3A4-2C15-4B31-81A8-C2E5892913F9@koalephant.com> <2d8efb96-ed1f-28e4-e0fe-603a2d0f1962@gmail.com> In-Reply-To: Date: Fri, 1 Feb 2019 18:46:32 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Rowan Collins Cc: Peter Kokot , Internals Content-Type: multipart/alternative; boundary="000000000000c5a8430580d2062b" Subject: Re: [PHP-DEV] Deprecation ideas for PHP 8 From: yohgaki@ohgaki.net (Yasuo Ohgaki) --000000000000c5a8430580d2062b Content-Type: text/plain; charset="UTF-8" On Thu, Jan 31, 2019 at 7:30 PM Rowan Collins wrote: > On Thu, 31 Jan 2019 at 07:34, Peter Kokot wrote: > > > Sorry, I didn't put my words correctly here. Not inconsistency. > > Inconsistency is a fact, yes. I've meant the incapability of doing > > something to fix this inconsistency. And it is becoming some sort of > > stubborn belief and less and less people want to fix it. > > > > The RFC: Consistent function names [1] shows the magnitude of this. I > > don't think every function listed there needs a change so it can be > > greatly reduced. But still this can be done in several years to 10 > > years or so (measuring over the thumb). > > > > > Hi, > > I'm sorry if I sound stubborn, but I have yet to see a reasonable answer to > the fundamental problem: the effort needed is not on the part of a few > volunteers changing the language, it is effort by *every single user of the > language*, rewriting *every single PHP program ever written*. > > WordPress officially supports both PHP 5.2, released 13 years ago, and PHP > 7.3, released a couple of months ago; one of their biggest challenges in > raising that bar is that they, too, have to persuade a community (the theme > and plugin authors) to change their code to match. That should give you > some idea of how long old and new names would have to exist side by side, > while we waited for everyone to rewrite all their code, and meanwhile, the > language would be *even more inconsistent*, because there would be extra > ways of writing the same thing. > Hi, Aliases may stay defined 10, 20 years or even forever for POSIX(IEEE) names. So there wouldn't be compatibility issues for CODING_STANDARD names. Christoph suggests namespace for renaming function. This works also. If namespace is used, it is better to have "PHP" namespace to keep user namespace clean. IMO. e.g. PHP\BC\add() This creates yet another inconsistency with existing modules, though. Bottom line is almost all developers dislike inconsistent names, prefer to enter extra few chars. Consistent name isn't big deal, but keeping inconsistent names for good doesn't sound nice. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --000000000000c5a8430580d2062b--