Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91569 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34257 invoked from network); 9 Mar 2016 10:10:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Mar 2016 10:10:14 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:22497] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 29/67-15119-486FFD65 for ; Wed, 09 Mar 2016 05:10:14 -0500 Message-ID: <29.67.15119.486FFD65@pb1.pair.com> To: internals@lists.php.net References: <1F.91.55238.41F10D65@pb1.pair.com><56D42CD3.6020602@gmail.com><56D57DF4.8000906@gmail.com><56D5D2AD.6070805@gmail.com><56D5DDA6.4080607@fleshgrinder.com><40.73.36499.548B6D65@pb1.pair.com><56D6BBD0.5010505@gmail.com><56D73386.3000903@fleshgrinder.com><86.68.21983.A2508D65@pb1.pair.com><56D86C00.6000904@fleshgrinder.com><56dd744b.8157620a.cddfc.74ed@mx.google.com><56DDEF7B.6080309@fleshgrinder.com><56DECE15.703@lsces.co.uk> In-Reply-To: Date: Wed, 9 Mar 2016 10:09:53 -0000 Lines: 7 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 80.177.120.119 Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal From: TonyMarston@hotmail.com ("Tony Marston") "Andrew Brown" wrote in message news:CAH=AbGJAnYK1Vra+7mU=Ldcb+9Tp6+qbT9yaVzX60GJ=YJsTnA@mail.gmail.com... > >the main argument against removing var that I continue to hear is that 'my >old code won't work anymore because of this unnecessary BC break'. but the >thing is, your code *will* continue to work. unless *you choose* to upgrade >your PHP version. We developers are constantly being told that we should *ALWAYS* upgrade to the latest release as soon as possible otherwise our code will be subject to security flaws. We would *LOVE* to upgrade without the fear of having our code stop working simply because some clever cloggs has broken the language simply removing a feature that was not doing any harm. >if you stay on the current major version, it will >continue to work just fine. just like your PHP4 constructors will continue >to work on version 4, etc, etc. PHP 4 constructors have always worked in PHP 5 simply because they were never deprecated. My PHP 4 code is still running with version 5.6.19 >Of course, someone will say, 'but I want the new features and speed >improvements', which is valid. But I feel it is unfair to the language >developers, with all of the work *they* put in, to expect that we as users >of the language don't have to put in any effort to upgrade to a new major >version. Apart from installing the new executables there should be *NO* additional effort required to upgrade. Valid code which ran in the previous version should also run in the new version. > and I would imagine changing your `vars` to `public` is a >*relatively* simple update, compared to some other possible BC breaks. Whether it is simple or not is irrelevant - it is not necessary in the first place. >If we, as application developers, had duplicate code, or code that was >often the source of confusion, we would probably do our best to remove the >duplication and confusion, even if (technically) the code wasn't >hurting/breaking anything. this makes our future work easier on ourselves >or future developers. I think it is unfair of us to expect any different >from the language maintainers. What we as userland developers do with our own code only affects us. What you as core developers do with the language affects every one of the millions of userland developers all over the world. It does not matter that certain features have alias names - all a confused developer has to do is RTFM and all confusion disappears. Unless an exiting feature or function causes a GENUINE problem then it should be left alone. No effort should be wasted in taking it out and pissing off a huge number of userland developers. You as core developers may not like it, but you are there to serve the needs of the userland community, NOT to enforce your personal preferences on that community. >here's an example that actually occurred in application code of mine. by an >oversight I had 2 helper functions named `validation_state()` and >`validationState()`. the intention of both was the same thing, and to start >they both did exactly the same thing. Some places in my app used >`validation_state` and some other places used `validationState()`. >technically the code worked, so I thought nothing of it. then one day I >made a minor change to `validation_state()` but forgot that >`validationState()` existed, and didn't make the changes there as well. >This caused inconsistencies in my application, and the problem was not >immediately apparent. after that occurred I decided to spend 30 minutes, >and completely remove the `validationState()` function, and replace all >occurrences of it with `validation_state()`. Yes, I had to put in a little >work, but it was worth it for cleaner, more consistent code. How many millions of developers did that change affect? How many applications did that affect? >consistency is key to make the language easy to understand for the language >maintainers, and for the language users, and especially for new users of >the language. Define "consistency". Consistency with what? -- Tony Marston