Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106990
MIME-Version: 1.0
References: <076701d56978$86020910$92061b30$@php.net> <CADyq6sK4HektgfDpCCFR3=bumyPaf9vn=-WdvaboHybBQKd53g@mail.gmail.com>
 <078e01d5697c$5512bc10$ff383430$@php.net> <CAKws9z1EBSqCFy2wD3cEV49KDSJOd6tT04PrCkxG8+3Hb6WpTA@mail.gmail.com>
 <CAPKYkKw1EU3Qp6W7b19r4kMKPD1HntH+7NQSxSiDNcLXqPERMA@mail.gmail.com>
 <CAKuGYLRWF9jnS-Zs+uRFNN1pgRSvHFpW-FChgNq9Rk282AFFGA@mail.gmail.com>
 <CAPKYkKxUyeWWZY5OyDLtAYiDUYLkwyMjuc_Wq2Y++3C9CP6G1w@mail.gmail.com> <CAAwbVudFMThRjxASCKDnwpXWt-Euv5VEYtN4XdsqXb5GBSiCig@mail.gmail.com>
In-Reply-To: <CAAwbVudFMThRjxASCKDnwpXWt-Euv5VEYtN4XdsqXb5GBSiCig@mail.gmail.com>
Date: Thu, 12 Sep 2019 13:51:59 -0400
Message-ID: <CAPKYkKw5APw+gHiZx+0SiUkb2OWNV_bK9fFQaMNAtL7qiJss3A@mail.gmail.com>
To: Olumide Samson <oludonsexy@gmail.com>
Cc: Matthew Brown <matthewmatthew@gmail.com>, Scott Arciszewski <scott@paragonie.com>, 
	Zeev Suraski <zeev@php.net>, Marco Pivetta <ocramius@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000057a0c05925ecc5b"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000057a0c05925ecc5b
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 12, 2019 at 1:39 PM Olumide Samson <oludonsexy@gmail.com> wrote:

>
>
> On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler <chasepeeler@gmail.com>
> wrote:
>
>> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown <matthewmatthew@gmail.com>
>> wrote:
>>
>> > that don't fundamentally change the language
>> >
>> >
>> > There's clearly a big disagreement about whether this is a fundamental
>> > change or not.
>> >
>> > Preventing something that the entire field of software engineering
>> frowns
>> > upon (and that most PHP developers avoid like the plague) doesn't seem
>> like
>> > a *fundamental* change.
>> >
>> >
>> I would argue that this is exactly such a change. The flexibility of PHP
>> has often been touted as a feature and something that sets it apart.
>> Whether that's good or bad is, frankly, irrelevant. There are valid
>> reasons
>> for not always initializing variables or array keys.
>
>  The major valid reason i see is creating a bolierplate or being lazy to
> initialize the variable with even null or similar null-type depending on
> its context.
>
> It might be a bad reason in your opinion, but others view it as perfectly
>> acceptable.
>
>  Who are those "others"?
> I think he(me included) is also one of those "others" that view it as bad
> programming style...
>
> For 20 years people have developed code based on that feature. It was never
>> considered an error, and often not even considered bad practice.
>
>  It was considered an error, that's why you were been warned or given
> notice that "Hey dude, you're writing a bad code here @ line 1427(l4zy) of
> already-problematic-file.php" and only if we want to remove Notice,Warning
> or Error in the language.
>

No, as discussed previously, notices were never meant to signify a definite
issue. They are "Hey, this might be an issue, it might not, maybe check it
out if you want?" thing. This RFC is proposing that we actually halt
execution of programs that currently work perfectly fine and run exactly as
they were intended to.


> To suddenly define it as such is the exact definition of a fundamental
>> change
>> to the language itself.
>>
> Fundamental is always "fundamental", i think there's no good definition
> for it in this context, so leave fundamental changes out of this discussion
> as something totally bad been cleaned up is a fundamental change and
> something new but not used right and changed to be used right is also
> fundamental...
>

I would said fundamental is any behavior that is expected and intended. At
this point, the fact that you don't have to initialize your variables is an
intended feature of the language. That means people should be able to
depend on such a feature existing. The fact that you don't like it
shouldn't be a justification for breaking that, especially when nothing is
stopping you from being as strict as you want with your own code. You can
also hold any third party libraries that you use to the same standard if
you want.


>
>> What if Java suddenly said that all properties are suddenly private, and
>> can only be accessed through getter/setter methods? The fact that you
>> should make properties private and use such methods is a practice that was
>> drilled into me from day one. Would that justify making such a change,
>> though?
>>
>> I'm not sure how this relates, i think Java would let you see the good or
> bad, it's up to you to see or not from their view, let the majority move
> forward and don't be a stopping stone in moving this language past the 1993
> bondage(needle-haystack, inconsistent naming and many issues we couldn't
> count)...
>

It relates because right now, it's a feature of Java that you can make
properties public and then modify those directly from outside the class.
Since it's an intended feature, a lot of people have written code that
directly accesses public properties.You could argue the only use-case for
doing so is that they are too lazy to write the getter/setter methods, but
that doesn't change the fact that such code exists and is not an error or
even a misuse of a current feature.


-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000057a0c05925ecc5b--