Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106609
MIME-Version: 1.0
References: <alpine.DEB.2.21.1908141608160.29731@singlemalt.home.derickrethans.nl>
 <CAESVnVo94dSgU7vf62aPO409cGU_WMFrw4FV-ABFiKiMKjWs1A@mail.gmail.com>
In-Reply-To: <CAESVnVo94dSgU7vf62aPO409cGU_WMFrw4FV-ABFiKiMKjWs1A@mail.gmail.com>
Date: Wed, 14 Aug 2019 11:58:15 -0400
Message-ID: <CAPKYkKzSEbB25Mx1ReqBnak3x7GqD7QrykfLn6DC9iEA=34yTg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d83221059015d3ed"
Subject: Re: [PHP-DEV] Vote: Straw poll for P++ feasibility
From: chasepeeler@gmail.com (Chase Peeler)

--000000000000d83221059015d3ed
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 14, 2019 at 11:27 AM Sara Golemon <pollita@php.net> wrote:

> On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans <derick@php.net> wrote:
>
> > https://wiki.php.net/rfc/p-plus-plus
> >
> > To follow up my no vote; What I'm against is splitting the language on
> hard boundaries that never disappear, only widen. I'm also a 'No' on
> Editions, but slightly less of a 'No', and possibly a 'Yes', if those
> editions are clearly intended to fade over time.
>
> -Sara
>
I'd vote "No" if I had a vote. I appreciate Zeev proposing the idea. I've
been as vocal as he has on the short tag issue, and generally fall into the
"avoid BC unless there are overwhelming positives" camp. Maybe I don't have
the complete picture since I don't actually do core development, but I have
been a professional PHP developer for 14 years (Thursday is my 14th
anniversary) and I've been using it for fun/school work for 20 years. From
what I've seen, there isn't near as much contention on BC breaks in general
as a solution like this would require in order to be justified. As someone
mentioned in another thread, the majority of the features discussed (union
types, annotations, enums, etc.) don't require BC breaks at all. Among
things that do require them (both new features and clean up of older
features), I see that most people, myself included, willing to accept them
once they have passed.

I definitely think it's possible to more PHP forward with lots of new
features, and even cleaning up some old and obsolete parts, without moving
too far in either extreme in terms of BC breaks. I also think that
internals has done a pretty good job of that up to this point, and have no
doubt they will continue to do so.

I don't know if it was just a coincidence in timing, but it feels to me
like this proposal was spurred, at least in part, by the discussions over
short tags. If so, I definitely think that it is an overreaction. I also
think the discussions on short tags show why even taking this proposed path
wouldn't solve anything in the long run. The discussion over short tags
have got pretty heated at times, but it seems to me that it is mainly
because both sides are just repeating their talking points without
discussing or answering the points made by the other side. I think that is
partly due to the discussion medium, and partly due to the diversity of the
participants. Without immediate feedback in a manner you expect, it's hard
to tell if the point you just typed out over 5 paragraphs actually made
sense to others that will read it. Bottom line, though, is that there will
be contentious debates about topics no matter what. You might be able to
avoid the debate on whether or not to require strict typing in P++, but
you've still got to decide on which types you're going to support. Strict
typing might never again need to be discussed in legacy PHP, but, there
will always be discussions about some of the more controversial ways that
types are juggled.

There might be a time in the future where I do feel like a proposal like
this is justified or even needed. I just don't feel we are at that point
right now, nor do I think we are headed towards it.

-- 
Chase Peeler
chasepeeler@gmail.com

--000000000000d83221059015d3ed--