On Mon, Mar 7, 2016 at 4:27 AM, <kelerest...@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é: ‎štvrtok‎, ‎3‎. ‎marca‎ ‎2016 ‎22‎:‎23
> 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 the
> > (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 change.
>
> --
> 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.

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Reply via email to