Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107039
MIME-Version: 1.0
References: <076701d56978$86020910$92061b30$@php.net> <CAKuGYLQA+XMHLGXPM4n_eEdp-d1=WzDE4Z4iLOzhD+4m83McaQ@mail.gmail.com>
 <467be4a0-dd8b-29d2-0b09-a3efd7fad56a@heigl.org> <CAJHtznwJLryZa1fWHXUJd5OS+9YKBjAj30fpN7sjR3By7a-DbQ@mail.gmail.com>
 <CAAfnsFU8B7gpd1=CpO+eDr7ogqDdFX7pZYNTT9rSoTDz+ybUQw@mail.gmail.com>
 <CANvqVdpiRRxO-9AvQJebvjKmL8454p7NLeirOZD7YKNhRzjjgg@mail.gmail.com>
 <CAAwbVue0Pb9_pHGexEsgOiDGutm8Uk-UarAg4KsTZirnwv3QJA@mail.gmail.com>
 <CANvqVdrozL53POuayum8ZoEC90XmaCfR8KLJvUfBGDTFJEUbeg@mail.gmail.com>
 <CAAwbVucrOBgVtC8BZe7KTJtj79He53XXxQ0WKGFTKFvL_pg40Q@mail.gmail.com>
 <CAPKYkKwcPEeKJyAvRy2ojU-+enODGkZKwkaXT-99wnH87TLF+w@mail.gmail.com>
 <CAAwdEzAm2uPg5yFCoi9CmBuSyViSojAcQFGs32MmG3weao6=8g@mail.gmail.com> <CAPKYkKwHpjF=JeVAsR9-HorUSPgPQGOkzdW9NirYn7PSffj2RQ@mail.gmail.com>
In-Reply-To: <CAPKYkKwHpjF=JeVAsR9-HorUSPgPQGOkzdW9NirYn7PSffj2RQ@mail.gmail.com>
Date: Fri, 13 Sep 2019 01:03:00 +0100
Message-ID: <CAAwbVudOG-uvE3YdaxUesLorsDkDNqbvfCPReztorfTJQEs8eQ@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>, 
	Michael Babker <michael.babker@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fae379059263fac0"
Subject: Re: [PHP-DEV] Changing fundamental language behaviors
From: oludonsexy@gmail.com (Olumide Samson)

--000000000000fae379059263fac0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 12, 2019, 10:15 PM Chase Peeler <chasepeeler@gmail.com> wrote:

>
>
> On Thu, Sep 12, 2019 at 4:59 PM Alexandru P=C4=83tr=C4=83nescu <drealecs@=
gmail.com>
> wrote:
>
>> Hi guys,
>>
>> > Many of us don't consider it bad code. I've also always initialized
>> > variables when it was required (and many times when it wasn't) even
>> though
>> > I wasn't forced to do so. A lot of other people do as well. If it's so
>> > important to you, start a program to teach people how you think they
>> should
>> > code.
>>
>> One problem that needs to be understood is that PHP is used by a lot of
>> users.
>> Because it's easy to pick up and you have fast feedback it probably have
>> a higher percentage of juniors than average.
>>
>
> I don't think "new developers might do it wrong" is a very compelling
> argument. We shouldn't handcuff the language because some people might us=
e
> the flexibility improperly.
>
>
>> How language was 10 years ago it didn't helped them much in learning and
>> they did lot of mistakes. Some of those mistakes cost companies lots of
>> money and, in time, people got to the conclusion that PHP is bad.
>> This is a very important thing!, Yes you can write working great code in
>> PHP but it's very easy to write working bad code as well. And it's not
>> about you and me or the other persons chatting here, it's about the rest=
 of
>> the world.
>>
>>
> And I don't think we should take away the flexibility that makes PHP grea=
t
> because some people don't use it correctly. "Billy can't code properly
> unless the the application crashes whenever he doesn't initialize a
> variable" isn't any more compelling when it's in the third person than it
> was in the first person.
>

I hate to see people taking PHP dynamic bug-friendly pattern as great
flexibility. Why would something be great and same time be bad?
Isn't that a contradiction?
PHP is great in flexibility for things like being dynamically typed, fast
to launch(major hosts always have it enabled), easier to understand but not
for allowing bugs that can cost huge money in the long run.

PHP is a very good friendly language when it comes to learning, yet the
worst language when it comes to ideology or roadmap.

Most companies only prefer PHP to make fast MVP, but as soon as that stage
passed, their HR would start searching for developers in other better
languages.

Check out stackoverflow and see how many buggy questions are asked daily.

>
>
>> PHP improved on it's bad image in the later years but this needs to
>> continue. IMO, one thing that we need to also do is to make the language
>> image better.
>> With this in mind, I believe the "undefined variable" error will be a
>> step forward.
>>
>>
> But it won't. People that won't a stricter language aren't going to start
> using PHP because it suddenly throws more errors than it used to. As I
> mentioned before, some non-PHP developers I knew find it appalling that
> such a massive BC break was even being considered. As much as they don't
> like the idea of uninitialized variables, the fact that they've been arou=
nd
> for 20 years and now there is talk of them making applications crash was
> much bigger issue.
>
> The way we improve PHPs image is we show why the things that make it
> unique are actually good things, while adding NEW features to the languag=
e.
> No matter how much we try to make PHP like Java, c#, python, etc., it isn=
't
> going to entice those developers over to PHP when PHP doesn't offer them
> anything different than what they already have.
>
>
>
>> It's not about if you don't consider it bad code and that apparently the
>> majority consider it good.
>> It's that if language wouldn't allow you to write that code it will
>> benefit the language image and the rest of the PHP comunity.
>>
>> Also, I would also like to remind of this:
>> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
>> I think some parts might have been violated multiple time in this thread=
.
>>
>>
> I can take the hint. This will likely be my last post on the topic. I
> think there are few others on this thread that can take up the fight from
> here on out.
>
>
>> Regards,
>> Alex
>>
>>
>> On Thu, Sep 12, 2019 at 10:29 PM Chase Peeler <chasepeeler@gmail.com>
>> wrote:
>>
>>> On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson <oludonsexy@gmail.com>
>>> wrote:
>>>
>>> > On Thu, Sep 12, 2019 at 8:11 PM Michael Babker <
>>> michael.babker@gmail.com>
>>> > wrote:
>>> >
>>> > > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson <oludonsexy@gmail.co=
m
>>> >
>>> > > wrote:
>>> > >
>>> > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker <
>>> > michael.babker@gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot <peterkokot@gmail.com=
>
>>> > >>> wrote:
>>> > >>>
>>> > >>> > Just a dumb idea, since there clearly is a majority in favor of
>>> the
>>> > >>> > change with these warnings and strictness and all that now...
>>> Why not
>>> > >>> > making something like an LTS PHP 7.x where all the legacy code
>>> would
>>> > >>> > work OK as long as practically possible and 8.x+ would be the
>>> future
>>> > >>> > of what the developers want and not what business wants? One wh=
o
>>> > won't
>>> > >>> > upgrade due to the BC breaks also won't need the new features
>>> anyway
>>> > >>> > very realistically.
>>> > >>> >
>>> > >>>
>>> > >>> Please don't tie the notion of LTS with the idea that a new major
>>> can
>>> > >>> break
>>> > >>> BC at will or create larger scale breaks because the previous
>>> major has
>>> > >>> extended support.  Sooner or later that will end up back at the +=
+
>>> idea
>>> > >>> and
>>> > >>> fragmentation encouraged by the language is a bad idea.
>>> > >>>
>>> > >>
>>> > >> Not sure you are really seeing the goal...
>>> > >>
>>> > >> Why is LTS not a good idea?
>>> > >>
>>> > >
>>> > > I'm not saying LTS is a bad idea.  I'm saying using LTS to justify
>>> > > shipping larger scale BC breaks, such as the changes suggested in t=
he
>>> > last
>>> > > couple of "contentious" RFCs in a major version because "hey, we
>>> have a
>>> > LTS
>>> > > version you can use that until you're ready to deal with the backlo=
g
>>> of
>>> > BC
>>> > > breaks created" is a bad idea.
>>> > >
>>> >
>>> >
>>> > > For the record, I happen to agree with as these RFCs would have
>>> minimal
>>> > > impact on my day-to-day work, but having also been in the role of a
>>> > > maintainer of open source libraries and applications I also grasp w=
hy
>>> > these
>>> > > types of changes can be problematic to the ecosystem (both end user=
s
>>> of
>>> > > those libraries and applications and the maintainers of them) and
>>> > wouldn't
>>> > > jump the gun to ship them without careful consideration.
>>> > >
>>> >
>>> > Most of these changes wouldn't have been problematic to you if the
>>> language
>>> > has prevented you from writing what we can now consider bad code, so
>>> please
>>> > allow the new PHP developer that newly start using PHP to not follow
>>> that
>>> > your path that will/might hunt him later in the future...
>>> >
>>> >
>>> Many of us don't consider it bad code. I've also always initialized
>>> variables when it was required (and many times when it wasn't) even
>>> though
>>> I wasn't forced to do so. A lot of other people do as well. If it's so
>>> important to you, start a program to teach people how you think they
>>> should
>>> code.
>>>
>>>
>>> > There a notices, warning and errors to inform you that this shouldn't
>>> have
>>> > been the use case of this feature and you chose to ignore it and now,
>>> we
>>> > are simplifying things and making those your errors teach you how to
>>> write
>>> > proper codes in the future, you're objecting..
>>>
>>>
>>> As has been discussed before, notices are not the same as warnings and
>>> errors.  Also, if those things are so wonderful, why can't you use them
>>> to
>>> catch the issues you are complaining you can't catch right now? Again,
>>> you
>>> are telling me there is something out there which will allow you to for=
ce
>>> yourself to write "good code" without forcing me to follow the same
>>> restrictions. Yet, you still feel it's necessary to not use those tools=
,
>>> and instead modify the entire language so that I am forced to follow wh=
at
>>> you deem best practices, even if I don't?
>>>
>>>
>>>
>>> > Why not just stay in PHP 7.x?
>>> >
>>> > Because other features that I want to utilize will also be added in P=
HP
>>> 8.
>>>
>>> Or were you implying you want hitch-free, no-modification upgrade to PH=
P
>>> 8
>>> > from PHP 7.0?
>>> >
>>>
>>> I never said that. Here we go again with the "I guess you are against a=
ll
>>> BC breaks" nonsense. If BC breaks are required to add new functionality=
,
>>> or, have a very minimal negative impact, then I don't have a problem wi=
th
>>> them. This is not one of those cases. It changes a fundamental aspect o=
f
>>> the language, an aspect that many people actually like, and it doesn't
>>> add
>>> any new features to the language, nor is it needed to add any new
>>> features
>>> to the language.
>>>
>>>
>>> > If yes, follow the best practices and not suppress error notices.
>>> >
>>> > Just My Opinion
>>> >
>>>
>>>
>>> --
>>> Chase Peeler
>>> chasepeeler@gmail.com
>>>
>>
>
> --
> Chase Peeler
> chasepeeler@gmail.com
>

--000000000000fae379059263fac0--