Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[M. W. Moe]

Hello,

if you would drop zend engine as is and the idea behind it (which is most
difficult thing to admit and accept),
then use llvm-core. Making:
-- lexer, parser grammar
-- reference counting
-- type hint policies
-- builtins container
-- JITTER for compatibility.
-- bytecode
-- LLVM bytecode
-- symbolicated machine code
-- and so on

it's like picking your nose; meaning easy-peasy: when you have that in
place creating an other
dialect and 1 of them will be same; or even experimenting new
features...

it  will benefit the language at all:
- runtime execution, memory, exception handler  (`normally` handled)
- extension ecosystem you could autopen biddings without introducing bugs
from people.

Best.




On Fri, Aug 16, 2019 at 10:38 AM Mark Randall  wrote:

> On 16/08/2019 17:40, Chase Peeler wrote
> > 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.
>
>
> Re: Entertainment, I'd liken it to something like watching the replay of
> a car crash. One really shouldn't, but one can't help but be mesmerised.
>
> Onto the matter of nuance in decisions, I agree that things should be
> done on a case-by-case basis, however, you have to have something to
> weigh the pros and cons against.
>
> Right now, so far as I can tell, the value of cleanup and improvement in
> any particular decision is undefined, because there's no general
> consensus on it.
>
> Take short open tags, there are cases made for and against, and in my
> opinion the strongest case for it is language cleanup, to have one fixed
> way of doing something that can be taught so future developers don't
> start wondering what the difference is between them.
>
> But what base weight does cleanup have? Is cleanup hugely important, or
> a complete non-factor that shouldn't be considered at all? If it's
> somewhere in between, where in between.
>
> It would never be used in absolute terms, it's always something that
> would strengthen or weaken other arguments. BC breaking cleanup for
> cleanups sake isn't really going to fly, but cleanup because a
> particular set of functions are inconsistent, or exhibit unintuitive
> behaviour, those ultimately all have to start with a consensus on if
> it's worth breaking something, or making something more complex
> (namespaced function aliases?) for the sake of making the language as a
> whole "better".
>
> My worry is that those with voting privileges on internals may end up
> splitting into two camps, and voting ideas up or down based on personal
> bias towards or against an underlying principle of clean-up and
> improvement or BC-supreme.
>
> I doubt it will come up _often_, but when it does, it seems to be
> incredibly disruptive. I would argue it needs a wider debate and then
> people should use the result of that debate to inform their voting,
> knowing that "PHP" has agreed to weigh certain general concepts in a
> particular way.
>
>
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Mark Randall]

On 16/08/2019 17:40, Chase Peeler wrote

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.



Re: Entertainment, I'd liken it to something like watching the replay of 
a car crash. One really shouldn't, but one can't help but be mesmerised.


Onto the matter of nuance in decisions, I agree that things should be 
done on a case-by-case basis, however, you have to have something to 
weigh the pros and cons against.


Right now, so far as I can tell, the value of cleanup and improvement in 
any particular decision is undefined, because there's no general 
consensus on it.


Take short open tags, there are cases made for and against, and in my 
opinion the strongest case for it is language cleanup, to have one fixed 
way of doing something that can be taught so future developers don't 
start wondering what the difference is between them.


But what base weight does cleanup have? Is cleanup hugely important, or 
a complete non-factor that shouldn't be considered at all? If it's 
somewhere in between, where in between.


It would never be used in absolute terms, it's always something that 
would strengthen or weaken other arguments. BC breaking cleanup for 
cleanups sake isn't really going to fly, but cleanup because a 
particular set of functions are inconsistent, or exhibit unintuitive 
behaviour, those ultimately all have to start with a consensus on if 
it's worth breaking something, or making something more complex 
(namespaced function aliases?) for the sake of making the language as a 
whole "better".


My worry is that those with voting privileges on internals may end up 
splitting into two camps, and voting ideas up or down based on personal 
bias towards or against an underlying principle of clean-up and 
improvement or BC-supreme.


I doubt it will come up _often_, but when it does, it seems to be 
incredibly disruptive. I would argue it needs a wider debate and then 
people should use the result of that debate to inform their voting, 
knowing that "PHP" has agreed to weigh certain general concepts in a 
particular way.




Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Chase Peeler]

On Fri, Aug 16, 2019 at 12:08 PM Mark Randall  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 .
>
> 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
chasepee...@gmail.com

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

On Fri, Aug 16, 2019, 5:08 PM Mark Randall  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 .
>
> 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.
>

On this last paragraph written below, I'm seriously with you on this.

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(Optional through declare directive) ,
> 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(the biggest weight ever) it should carry.
>

Just in case a poll is needed, I added my +1 on the whole section you wrote
last.

>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Mark Randall]

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 .


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Christoph M. Becker]

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 .

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Peter Kokot]

Hello,

On Wed, 14 Aug 2019 at 17:14, Derick Rethans  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Zeev Suraski]

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

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

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  wrote:

>
>
> On Thu, Aug 15, 2019, 3:20 AM Olumide Samson 
> wrote:
>
>> On Thu, Aug 15, 2019, 10:52 AM Peter Kokot  wrote:
>>
>> > On Wed, 14 Aug 2019 at 22:41, Zeev Suraski  wrote:
>> > >
>> > > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans 
>> 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
>
>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Kris Craig]

On Thu, Aug 15, 2019, 3:20 AM Olumide Samson  wrote:

> On Thu, Aug 15, 2019, 10:52 AM Peter Kokot  wrote:
>
> > On Wed, 14 Aug 2019 at 22:41, Zeev Suraski  wrote:
> > >
> > > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans  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

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

On Thu, Aug 15, 2019, 10:52 AM Peter Kokot  wrote:

> On Wed, 14 Aug 2019 at 22:41, Zeev Suraski  wrote:
> >
> > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans  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.

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Peter Kokot]

On Wed, 14 Aug 2019 at 22:41, Zeev Suraski  wrote:
>
> On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans  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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Zeev Suraski]

On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans  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

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Olumide Samson]

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  wrote:

> On Wed, Aug 14, 2019 at 11:27 AM Sara Golemon  wrote:
>
> > On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  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
> chasepee...@gmail.com
>

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Ben Ramsey]

> On Aug 14, 2019, at 11:14, Derick Rethans  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


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Chase Peeler]

On Wed, Aug 14, 2019 at 11:27 AM Sara Golemon  wrote:

> On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  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
chasepee...@gmail.com

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[sergey]

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: ser...@s-panteleev.ru
On 14 Aug 2019, 18:27 +0300, Sara Golemon , wrote:
> On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  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

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

[Sara Golemon]

On Wed, Aug 14, 2019 at 10:14 AM Derick Rethans  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

[PHP-DEV] Vote: Straw poll for P++ feasibility

[Derick Rethans]

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

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Become my Patron: https://www.patreon.com/derickr
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php