Vote: Straw poll for P++ feasibility

Sara Golemon

7 years ago

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

Сергей Пантелеев

7 years ago

Hi!

my 2c:

As I understood, Zeev said about two camps: ones want to make PHP more strict, others – not.

Maybe, is more productive to discuss the general direction of PHP (it will be a strict road or not) instead of 4 months disputes about short open tags, or sisters language or other derivative things?

IMHO, if there is a single direction, many disputes will disappear by themselves

—
Sincerely,
Sergey Panteleev
Telegram: @saundefined
E-mail: sergey@s-panteleev.ru
On 14 Aug 2019, 18:27 +0300, Sara Golemon <pollita@php.net>, wrote:

Chase Peeler

7 years ago

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

Olumide Samson

7 years ago

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:

Ben Ramsey

7 years ago

> On Aug 14, 2019, at 11:14, Derick Rethans <derick@php.net> wrote:
>
> Hi,
>
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this. Hence, I've created a document in the wiki as a poll:
>
> https://wiki.php.net/rfc/p-plus-plus

I voted "no." While I've not contributed to the discussions here, I've
been following them and also reading what many on Twitter have been
saying.

I'll admit, I liked the idea of P++ for the novelty of it, but as the
past has proven, we can continue to provide greater type safety in PHP,
while retaining the dynamic character and flexibility that many enjoy.
In short, the internals team has done a great job of allowing us to
have our cake and eat it, too.

Sara shared this a few days ago, and I’d like to reiterate it:

> Strict(er) typing - I'm not sure, on the surface, what future expansions
> we'd plan for in this area which couldn't fit into standard PHP in a non
> BC-breaking way.

There have been a few people on Twitter floating up the idea of
something like TypeScript for PHP. This might be a better approach for
those who want to significantly diverge from PHP proper. Already, it is
possible to build something like this and have it transpile to PHP. In
the future, perhaps it could even compile down into Zend opcodes that
could be loaded directly into the PHP interpreter. Either way, it
wouldn't change PHP itself, but it could provide the syntactic sugar
and improved type-safety that folks are looking for. More importantly,
it wouldn't split the community or internals.

Cheers,
Ben

Zeev Suraski

7 years ago

On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans <derick@php.net> wrote:

> Hi,
>
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this. Hence, I've created a document in the wiki as a poll:
>

All,

Using a humoristic tone, I'm happy that finally internals@ is so unified.
I almost get the feeling that you may not like the idea...

On a more serious note, I'll keep the feedback on the validity of this vote
in just about every aspect (process, jurisdiction, anything really) to
myself, and say just two things:

- The P++ idea makes absolutely no sense in vacuum.  The reception around
this idea implied a decision between 'one big happy family' and 'a split'.
Since at this stage these are the perceived choices - I'd vote against it
too (which I just did, why not).  However, I believe it's a false choice.

- It will absolutely make sense to discuss it when it'll start becoming
clearer to everyone that 'one big happy family' is really not an option.
We'd be choosing how to soft split the family - granularly (2^n dialects),
into many editions (n dialects), or into two separate dialects with clearer
mandates (2 dialects).  I get it that it's intangible for many of us
(myself included, to a degree), which is why this idea is perceived as the
'evil splitter' for everyone to unite and rally against.  Maybe I'm wrong,
and the changes/features that I think are about to make it into PHP aren't
going to require any sort of split.  If that's the case - it's indeed a
horrible idea.  We'd only be able to see that a but further down the road.
It's definitely too early to spend that level of energy on it at this stage
- but at the same time, it will definitely make sense to explore it if &
when the reality I think we're going to be facing would begin to unfold.

I will not be responding to any further emails on this thread;  I'll
happily reply to private messages though.

Thanks,

Zeev

Peter Kokot

7 years ago

On Wed, 14 Aug 2019 at 22:41, Zeev Suraski <zeev@php.net> wrote:

>
> On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans <derick@php.net> wrote:
>
> > Hi,
> >
> > In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> > Before we end up spending this project's time and energy to explore this
> > idea further, I thought it'd be wise to see if there is enough animo for
> > this. Hence, I've created a document in the wiki as a poll:
> >
>
> All,
>
> Using a humoristic tone, I'm happy that finally internals@ is so unified.
> I almost get the feeling that you may not like the idea...
>
> On a more serious note, I'll keep the feedback on the validity of this vote
> in just about every aspect (process, jurisdiction, anything really) to
> myself, and say just two things:
>
> - The P++ idea makes absolutely no sense in vacuum.  The reception around
> this idea implied a decision between 'one big happy family' and 'a split'.
> Since at this stage these are the perceived choices - I'd vote against it
> too (which I just did, why not).  However, I believe it's a false choice.
>
> - It will absolutely make sense to discuss it when it'll start becoming
> clearer to everyone that 'one big happy family' is really not an option.
> We'd be choosing how to soft split the family - granularly (2^n dialects),
> into many editions (n dialects), or into two separate dialects with clearer
> mandates (2 dialects).  I get it that it's intangible for many of us
> (myself included, to a degree), which is why this idea is perceived as the
> 'evil splitter' for everyone to unite and rally against.  Maybe I'm wrong,
> and the changes/features that I think are about to make it into PHP aren't
> going to require any sort of split.  If that's the case - it's indeed a
> horrible idea.  We'd only be able to see that a but further down the road.
> It's definitely too early to spend that level of energy on it at this stage
> - but at the same time, it will definitely make sense to explore it if &
> when the reality I think we're going to be facing would begin to unfold.
>
> I will not be responding to any further emails on this thread;  I'll
> happily reply to private messages though.
>
> Thanks,
>
> Zeev

Hello @everyone,

this then also means that PHP will now never be a consistent language
and short tags will be forever in so we will all be able to support
Chase's gigantic legacy project forever?

Solution would be if we can make this issue that was mentioned:
- elephpant vs elep++ant

into a similar issue as is now:
- elephpant vs elephpantwithstricttypes
(non existent issue - all part of the one PHP itself)

--
Peter Kokot

Olumide Samson

7 years ago

On Thu, Aug 15, 2019, 10:52 AM Peter Kokot <peterkokot@gmail.com> wrote:

> On Wed, 14 Aug 2019 at 22:41, Zeev Suraski <zeev@php.net> wrote:
> >
> > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans <derick@php.net> wrote:
> >
> > > Hi,
> > >
> > > In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> > > Before we end up spending this project's time and energy to explore
> this
> > > idea further, I thought it'd be wise to see if there is enough animo
> for
> > > this. Hence, I've created a document in the wiki as a poll:
> > >
> >
> > All,
> >
> > Using a humoristic tone, I'm happy that finally internals@ is so
> unified.
> > I almost get the feeling that you may not like the idea...
> >
> > On a more serious note, I'll keep the feedback on the validity of this
> vote
> > in just about every aspect (process, jurisdiction, anything really) to
> > myself, and say just two things:
> >
> > - The P++ idea makes absolutely no sense in vacuum.  The reception around
> > this idea implied a decision between 'one big happy family' and 'a
> split'.
> > Since at this stage these are the perceived choices - I'd vote against it
> > too (which I just did, why not).  However, I believe it's a false choice.
> >
> > - It will absolutely make sense to discuss it when it'll start becoming
> > clearer to everyone that 'one big happy family' is really not an option.
> > We'd be choosing how to soft split the family - granularly (2^n
> dialects),
> > into many editions (n dialects), or into two separate dialects with
> clearer
> > mandates (2 dialects).  I get it that it's intangible for many of us
> > (myself included, to a degree), which is why this idea is perceived as
> the
> > 'evil splitter' for everyone to unite and rally against.  Maybe I'm
> wrong,
> > and the changes/features that I think are about to make it into PHP
> aren't
> > going to require any sort of split.  If that's the case - it's indeed a
> > horrible idea.  We'd only be able to see that a but further down the
> road.
> > It's definitely too early to spend that level of energy on it at this
> stage
> > - but at the same time, it will definitely make sense to explore it if &
> > when the reality I think we're going to be facing would begin to unfold.
> >
> > I will not be responding to any further emails on this thread;  I'll
> > happily reply to private messages though.
> >
> > Thanks,
> >
> > Zeev
>
> Hello @everyone,
>
> this then also means that PHP will now never be a consistent language
> and short tags will be forever in so we will all be able to support
> Chase's gigantic legacy project forever?
>

Solution would be if we can make this issue that was mentioned:

> - elephpant vs elep++ant
>
> into a similar issue as is now:
> - elephpant vs elephpantwithstricttypes
> (non existent issue - all part of the one PHP itself)
>

Zeev(Or anyone with such energy) can take up the game with same energy
he(Zeev) took the *elep++ant *up and I bet everyone (or the majority) would
really love the newer idea(elephpant vs elephpantwithstricttypes) and
probably take it up as a non issue coz it is all in the same part of the
one PHP itself(which already have its niche and brand).

And, IMHO the strict type or cleaner version of PHP would improve many
sections of the language and even help with future implementations(maybe
sooner we might even implement more evolved and consistent aliases of
current C styled function naming) all of these and more in the same PHP
we've known.

Or perhaps, an idea is to take a break on new implementations and make some
great changes which will pave way for great ideas and innovations.

All of this are good ideas internals@ should be debating, I guess.

Kris Craig

7 years ago

On Thu, Aug 15, 2019, 3:20 AM Olumide Samson <hisamsonolu@gmail.com> wrote:

> On Thu, Aug 15, 2019, 10:52 AM Peter Kokot <peterkokot@gmail.com> wrote:
>
> > On Wed, 14 Aug 2019 at 22:41, Zeev Suraski <zeev@php.net> wrote:
> > >
> > > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans <derick@php.net> wrote:
> > >
> > > > Hi,
> > > >
> > > > In the last week(s) there has been a lot of chat about Zeev's P++
> idea.
> > > > Before we end up spending this project's time and energy to explore
> > this
> > > > idea further, I thought it'd be wise to see if there is enough animo
> > for
> > > > this. Hence, I've created a document in the wiki as a poll:
> > > >
> > >
> > > All,
> > >
> > > Using a humoristic tone, I'm happy that finally internals@ is so
> > unified.
> > > I almost get the feeling that you may not like the idea...
> > >
> > > On a more serious note, I'll keep the feedback on the validity of this
> > vote
> > > in just about every aspect (process, jurisdiction, anything really) to
> > > myself, and say just two things:
> > >
> > > - The P++ idea makes absolutely no sense in vacuum.  The reception
> around
> > > this idea implied a decision between 'one big happy family' and 'a
> > split'.
> > > Since at this stage these are the perceived choices - I'd vote against
> it
> > > too (which I just did, why not).  However, I believe it's a false
> choice.
> > >
> > > - It will absolutely make sense to discuss it when it'll start becoming
> > > clearer to everyone that 'one big happy family' is really not an
> option.
> > > We'd be choosing how to soft split the family - granularly (2^n
> > dialects),
> > > into many editions (n dialects), or into two separate dialects with
> > clearer
> > > mandates (2 dialects).  I get it that it's intangible for many of us
> > > (myself included, to a degree), which is why this idea is perceived as
> > the
> > > 'evil splitter' for everyone to unite and rally against.  Maybe I'm
> > wrong,
> > > and the changes/features that I think are about to make it into PHP
> > aren't
> > > going to require any sort of split.  If that's the case - it's indeed a
> > > horrible idea.  We'd only be able to see that a but further down the
> > road.
> > > It's definitely too early to spend that level of energy on it at this
> > stage
> > > - but at the same time, it will definitely make sense to explore it if
> &
> > > when the reality I think we're going to be facing would begin to
> unfold.
> > >
> > > I will not be responding to any further emails on this thread;  I'll
> > > happily reply to private messages though.
> > >
> > > Thanks,
> > >
> > > Zeev
> >
> > Hello @everyone,
> >
> > this then also means that PHP will now never be a consistent language
> > and short tags will be forever in so we will all be able to support
> > Chase's gigantic legacy project forever?
> >
>
> Solution would be if we can make this issue that was mentioned:
> > - elephpant vs elep++ant
> >
> > into a similar issue as is now:
> > - elephpant vs elephpantwithstricttypes
> > (non existent issue - all part of the one PHP itself)
> >
>
> Zeev(Or anyone with such energy) can take up the game with same energy
> he(Zeev) took the *elep++ant *up and I bet everyone (or the majority) would
> really love the newer idea(elephpant vs elephpantwithstricttypes) and
> probably take it up as a non issue coz it is all in the same part of the
> one PHP itself(which already have its niche and brand).
>
> And, IMHO the strict type or cleaner version of PHP would improve many
> sections of the language and even help with future implementations(maybe
> sooner we might even implement more evolved and consistent aliases of
> current C styled function naming) all of these and more in the same PHP
> we've known.
>
> Or perhaps, an idea is to take a break on new implementations and make some
> great changes which will pave way for great ideas and innovations.
>
> All of this are good ideas internals@ should be debating, I guess.
>

Current vote is 39 - 0 in favor of rejection.  Who would've guessed this
discussion would wind up being an exercise in unity lol....

Olumide Samson

7 years ago

Power of democracy, maturity and love(for this same project PHP), I guess.

If this same love and energy could be put in place to know the directions
and future PHP hold(like are we moving forward or not), that will seriously
be a game changer.

On Thu, Aug 15, 2019, 2:00 PM Kris Craig <kris.craig@gmail.com> wrote:

Zeev Suraski

7 years ago

I did not intent to write anything else in this thread, but since someone
reverted the edits I made to fix the description of the P++ idea in the
poll, I have to.

One of the many ways in which this poll was problematic is that it
substantially misrepresents the idea - while claiming that this is in fact
what is being discussed/proposed.

I edited the description to reflect what the idea actually is - and given
that it’s my idea, I’m in the best position to do that (some of these
misconceptions were even explicitly handled in the FAQ).  Other than fixing
the errors in presenting it (and still doing so very surgically) - I
corrected two factual errors (type safety in languages is roughly as modern
as VCRs - i.e. not really, and this isn’t an RFC - but an informal vote).
I also added a time qualifier at the end - “at this time”, which is the
only non-factual edit I made, and that I don’t mind dropping anyway as this
poll has no formal standing (and don’t worry, I have no intention to
continue discussing it anytime soon regardless).

You can see the edited version that was reverted here:
https://wiki.php.net/rfc/p-plus-plus?rev=1565816351
I purposely took the time to do it in a “track changes” kind of way, so
that people can see both the original version and the corrected version.

To be clear - I’m not asking for a revote or anything of the sort.  I
really want to put this poll behind us all (I’m sure we all do), but can’t
live with this grossly misrepresented version of my own idea being somehow
validated as authentic by being on a vote - as non binding and informal as
this vote is.

Thanks,

Zeev

Peter Kokot

7 years ago

Hello,

On Wed, 14 Aug 2019 at 17:14, Derick Rethans <derick@php.net> wrote:

>
> Hi,
>
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this. Hence, I've created a document in the wiki as a poll:
>
> https://wiki.php.net/rfc/p-plus-plus

Off topic question/request if it's maybe possible and doable unless
I've missed something. Current RFC process is in short something like
writing a text document together with the implementation itself via a
pull request already and at the same time the discussion phase is
happening. After discussion there is a voting phase based on the
feedback from the comments. There, many times people who vote also
sometimes don't add reasons why they vote against something and they
stop the RFC from passing. RFC author, not only cannot implement it
but they also waste their time with the implementation.

Would it be a good thing if the RFC author would have a similar option
to get voting results feedback before starting to code (implementation
phase) on the RFC? So, they can see the results before the voting
phase and if the time investment is worth the trouble of adding a
feature or not.

Thank you.

--
Peter Kokot

Christoph Becker

7 years ago

On 16.08.2019 at 01:39, Peter Kokot wrote:

> Off topic question/request if it's maybe possible and doable unless
> I've missed something. Current RFC process is in short something like
> writing a text document together with the implementation itself via a
> pull request already and at the same time the discussion phase is
> happening. After discussion there is a voting phase based on the
> feedback from the comments. There, many times people who vote also
> sometimes don't add reasons why they vote against something and they
> stop the RFC from passing. RFC author, not only cannot implement it
> but they also waste their time with the implementation.
>
> Would it be a good thing if the RFC author would have a similar option
> to get voting results feedback before starting to code (implementation
> phase) on the RFC? So, they can see the results before the voting
> phase and if the time investment is worth the trouble of adding a
> feature or not.

It is not necessarily required to have an implementation for an RFC
available, see item (6) in <https://wiki.php.net/rfc/howto>.

--
Christoph M. Becker

Mark Randall

7 years ago

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 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.

Mark Randall