Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91530
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56dd744b.8157620a.cddfc.74ed@mx.google.com>
References: <1F.91.55238.41F10D65@pb1.pair.com>
	<CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
	<CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
	<FA.10.10408.29514D65@pb1.pair.com>
	<56D42CD3.6020602@gmail.com>
	<DB.E1.07778.3D165D65@pb1.pair.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>
Date: Mon, 7 Mar 2016 11:02:30 -0800
Message-ID: <CAMPTd_BvX-vcnm5UejW8B_162AVmVx_+9a=EpZX3yn5hz5dxfw@mail.gmail.com>
To: kelerest123@gmail.com, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114333324b11c7052d7a1b61
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: walterp@gmail.com (Walter Parker)

--001a114333324b11c7052d7a1b61
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 7, 2016 at 4:27 AM, <kelerest123@gmail.com> wrote:

> > Change for the sake of change is bad, no argument there. Change for the
>
> > sake of progress is not and totally normal.
>
>
>
> Can you please specify what kind of progress do see in the `var` keyword
> removal? I see only a BC break.
>
>
>
>
> Very best regards,
> Kubis Pandian-Fowler
>
>
>
>
>
>
> Od: Fleshgrinder
> Odoslan=C3=A9: =E2=80=8E=C5=A1tvrtok=E2=80=8E, =E2=80=8E3=E2=80=8E. =E2=
=80=8Emarca=E2=80=8E =E2=80=8E2016 =E2=80=8E22=E2=80=8E:=E2=80=8E23
> Komu: internals@lists.php.net
>
>
>
>
>
> On 3/3/2016 10:34 AM, Tony Marston wrote:
> > If you want to avoid such confusion over alias names then surely that
> > would be an argument against introducing aliases in the first place. In
> > this case the short array syntax would never have been introduced as th=
e
> > (only slightly longer) long array syntax had already existed since day
> #1.
>
> No, that is not what one should conclude from it. Short array syntax was
> added by popular demand and hence for a very good reason. The fact that
> there are no plans regarding the old syntax and thus keeping the
> duplication indefinitely is the actual problem.
>
> Change for the sake of change is bad, no argument there. Change for the
> sake of progress is not and totally normal.
>
> On 3/3/2016 2:04 PM, Rowan Collins wrote:
> > I'm not sure what Lester had in mind, but in many cases legacy code
> > which used "var" should actually be updated to mark properties as
> > "protected" or "private" instead. Such properties are public only
> > because PHP4 had no other visibility, and explicitly marking them all
> > "public" simply masks the real job, which is assessing which
> > visibility each property should have.
> >
> > It occurs to me that if I saw "var", I would not think "that should be
> > public", but "that needs assessing for visibility". I do the same with
> > legacy code where methods are written as "function foo()" rather than
> > "public function foo()" - I check whether it should actually be
> > public, and also in that case whether it should be static.
>
> It seems as if this is not the issue for the people who are against
> removing the "var" keyword from PHP 8. They simply do not want to change
> their scripts at all. The described procedure is truly time consuming
> since it involves to check all usages everywhere as well. Simply
> changing from "var" or "public" to any other visibility is a brutal chang=
e.
>
> --
> Richard "Fleshgrinder" Fussenegger
>


It is a disagreement over language design, the Python way vs the Perl way.
The Perl way says: There is more than one way to do things
The Python way says: There is one correct way to do things. Other methods
should be removed.

There is a desire among some PHP people to have the language be more like
the Python mindset.

--=20
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandei=
s

--001a114333324b11c7052d7a1b61--