Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106614
MIME-Version: 1.0
References: <alpine.DEB.2.21.1908141608160.29731@singlemalt.home.derickrethans.nl>
 <CAESVnVo94dSgU7vf62aPO409cGU_WMFrw4FV-ABFiKiMKjWs1A@mail.gmail.com> <CAPKYkKzSEbB25Mx1ReqBnak3x7GqD7QrykfLn6DC9iEA=34yTg@mail.gmail.com>
In-Reply-To: <CAPKYkKzSEbB25Mx1ReqBnak3x7GqD7QrykfLn6DC9iEA=34yTg@mail.gmail.com>
Date: Wed, 14 Aug 2019 18:24:53 +0100
Message-ID: <CAEm8qBQxiPCV-zb2COZ04RpxsGD1UU2GLApKFO2=W2J4MvaJgw@mail.gmail.com>
To: Chase Peeler <chasepeeler@gmail.com>
Cc: Sara Golemon <pollita@php.net>, Derick Rethans <derick@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002583fd0590170a3f"
Subject: Re: [PHP-DEV] Vote: Straw poll for P++ feasibility
From: hisamsonolu@gmail.com (Olumide Samson)

--0000000000002583fd0590170a3f
Content-Type: text/plain; charset="UTF-8"

I would say, PHP needs a direction(where're we headed?) than having a split
language.

Seriously, the core team have *tons of kudos* from the outside world(even
outside of PHP) and i think something called for those serious
implementation and i believe everyone(or simply put, the majority) one day
would see the need to make many improvements where necessary.

P++(Or other name it gets) is another project.

On Wed, Aug 14, 2019 at 4:58 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> 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
>

--0000000000002583fd0590170a3f--