Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106637
MIME-Version: 1.0
References: <alpine.DEB.2.21.1908141608160.29731@singlemalt.home.derickrethans.nl>
 <CAAfnsFX_z3oyJ6-sj7K9+LR690cCOAXoy0x7MtWqb6eUrFQThw@mail.gmail.com>
 <6534c240-e721-d5c1-a98c-86dfb9189b00@gmx.de> <5d56d50a.1c69fb81.26bc6.e2cdSMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5d56d50a.1c69fb81.26bc6.e2cdSMTPIN_ADDED_MISSING@mx.google.com>
Date: Fri, 16 Aug 2019 12:40:23 -0400
Message-ID: <CAPKYkKzesU4Dr8EFDUepvxBKau5jjzc9pMVr9zeaXET2LKgV=g@mail.gmail.com>
To: Mark Randall <markyr@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000032fee705903ea698"
Subject: Re: [PHP-DEV] Vote: Straw poll for P++ feasibility
From: chasepeeler@gmail.com (Chase Peeler)

--00000000000032fee705903ea698
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 16, 2019 at 12:08 PM Mark Randall <markyr@gmail.com> wrote:

> On 16/08/2019 11:18, Christoph M. Becker wrote:
> > It is not necessarily required to have an implementation for an RFC
> > available, see item (6) in <https://wiki.php.net/rfc/howto>.
>
> I have enormous respect for Derick, but I can't help but feel this "RFC"
> was bodged from the start.
>
> There's certainly a place for straw polls, the ability to receive quick
> feedback on opinions and sentiment can be a positive thing in a lot of
> circumstances. This however, seemed more like an invitation for
> internals developers to express that they wouldn't entertain spending
> any time on the proposal, in effect forcefully slamming the door shut on
> it before a proper discussion had been had.
>
> The end result did seem to be like watching Zeev be thrown to the lions
> in the colosseum. While entertaining for a short time, I believe it left
> something of a sour taste in the mouth, and it certainly did not present
> internals well to the outside world. The hasty edits to the Wiki then
> made it worse, and so on.
>
> I agree (although I didn't really find it entertaining for a short time).
As I said (or at least tried to say) in my previous comments on this
thread, I don't think Zeev's ideas were necessarily bad, just unwarranted
at this time. Unless I'm misunderstanding him, I think he, at least
somewhat, feels that way as well. He sees some issues coming down the road
and made this proposal as an attempt to prevent them. Others, myself
included, seem to feel that the problems he foresees aren't going to
happen, or at least aren't inevitable. As such, I wasn't so much saying
that P++, editions, or other similar ideas are totally off the table
forever and ever... just that we should wait until we reach a point where
one of them is necessary, since there is a good chance we won't ever reach
that point.

I encourage Zeev to continue refining and fine tuning his ideas, so that if
we do reach that point, we can hit the ground running. Until then, I think
any discussion on this mailing list goes beyond the level of "informal" and
takes focus away from advancing the language.


> I believe for anything remotely positive to come out of this whole
> affair, things need to quickly and visibly pivot to a meaningful
> discussion about the long term game plan for PHP, and build a consensus
> on things such as strict typing, overloading in the core functions, and
> perhaps most divisively, if "cleaning up the language" is in itself a
> viable justification for backwards compatibility breaks, and if so, what
> weight it should carry.
>
> I personally don't see this as necessary. I think it's safe to say that
anything is on the table. Every change needs to properly weigh the
positives and negatives. A new feature might be in high demand and cause no
BC issues, but, the resources required to build it prevent 10 other
slightly less highly demanded features. As was mentioned earlier, a lot of
the more sought after features (union types, enums, annotations, etc) don't
require BC breaks at all. What's holding them back isn't a lack of vision
or purpose either - it's the difficulty of implementing them.

A BC break to clean up the language might be justified in one case, and not
in another. To make a blanket statement that we will or will not attempt to
clean up the language is not wise in my opinion. It puts the project in a
bad place if it's forced to stick to it's decision, or, it makes the whole
reason for having made a decision pointless if we keep finding certain
items that are exceptions.


> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepeeler@gmail.com

--00000000000032fee705903ea698--