Re: [PHP-DEV][RFC] Allow void return type variance

[Wes]

Hi!

PHPUnit 8 changed e.g.  `  function setUp(){}` to  `  function setUp():
void{} `   and a lot of people did not like being forced to do the same on
their  `setUp()`.

The issue is not PHPUnit adding `void`, but PHP forcing `void` even when
it's not necessary. If PHPUnit wants to use void but inheritors don't want
to, it should just be possible.

"probably a bad idea" is opinionated, in reality there is no provable
reason to disallow it, from a pure type-theory standpoint.

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Stanislav Malyshev]

Hi!

> Without a required discussion period, there could be slightly more
> 'incentive' for RFC authors to respond as quickly as possible, to 'get
> the discussion out the way'.

I see it exactly opposite - since we have no quorum requirement,
declaring the vote as soon as possible if a couple of people like your
proposal and nobody objected yet seems to be winning strategy. By the
time people analyze it more in detail and decide to voice objections the
vote would be half done, and by the time they read the answers and want
to continue the discussion, the vote would be finished. The right thing
in this scenario would be to vote "no" immediately to any RFC that you
didn't read yet and then start the discussion. This looks like rather
wrong process.

> It should be made really clear to people raising RFCs, that choosing
> to have the minimum voting time, particularly if the discussion didn't
> seem to produce a clear consensus can be, and possibly should be,
> interpreted by voters as a reason to vote against an RFC.

The problem, again, is, as you said, you don't read internals for weeks.
I may also have periods where this happens, and I suspect others too.
Now you come back and discover a blitz RFC already in the second week of
voting, and you don't even know what it's about. So your choice is -
read it and ask questions now, and take chance that the vote would be
done before you even get an answer, or immediately vote "no" on all
unknown RFCs and then maybe change your vote later. I don't think
encouraging such things would create a good process or be encouraging to
new RFC authors.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Stanislav Malyshev]

Hi!

> 1. There is no required discussion period. However, if an RFC vote is
> opened without leaving enough time for discussion, then voters can and
> should vote the RFC down on the grounds of insufficient discussion.

I don't think this is a good idea. I see no scenario it improves -
there's nothing in any RFC that can't wait for a week or two. However,
there can be then a situation where somebody sees something as obvious
and declares immediate vote, while others think it's not obvious at all
but by the time they get there the vote is already done. I see
absolutely no need to speed it up - the RFCs that ever got stalled
didn't get stalled because of mandatory discussion period. This tries to
solve a problem we don't have with something that may have bad
consequences.

> and require more time for an adequate discussion. Other RFCs are simple and
> of limited scope (such as an extension function addition) and do not
> require extensive discussion.

Yes, some RFCs are simple. But none of them are urgent. And frankly if
the proposed can't stay on track for two weeks

> While a two week discussion period should remain a good guideline for
> language-related RFCs, it is up to the RFC author to decide when opening an
> RFC vote is appropriate. This will depend both on the scope of the RFC

This is also not a good idea - I can easily see unexperienced RFC author
setting discussion period too short, because it's obviously a good idea,
people that didn't have time to understand the RFC vote no, as you
recommended, and then RFC fails not on merits but because of easily
avoidable process issue. Better to avoid it upfront.

> 2. There is no moratorium period after an RFC vote fails. If you think that
> you have made significant progress on an RFC and resolved the issues that
> made the previous vote fail, you can give it another shot at any time,
> without having to wait out some fixed period.

Obvious failure scenario is to submit the same RFC with minimal cosmetic
changes in hope detractors gave up or don't pay attention (either
explicit or implicit - i.e. genuinely thinking the RFC was fixed but not
actually fixing it) and essentially subverting the consensus. Coupled
with no minimum discussion period I think this can happen a lot,
especially given that many people don't have time to read all discussion
on all topics on the list in real time (I don't for example).

> A failed vote does not (necessarily) mean that a feature is not wanted. It
> is quite common for significant changes to fail on first vote, due to
> issues in the initial proposal. A failed vote should not be a
> discouragement, but a motivation to address problems expressed during
> discussion or voting.

True, but I don't see how having cooldown period contradicts this.
That's exactly when the problems have to be fixed. What's the point of
putting up for vote an RFC that just yesterday have failed a vote (your
reform allows this)?

> Essentially, this is about making the RFC process more suitable for changes
> small and large, and empowering both RFC authors and the voter base to make
> decisions that are appropriate for each RFC.

I do not see which decisions it enables that will improve the process.
So far I only see the decisions that if enabled would likely to lead to
more controversial decisions passing and more people being left behind
or unable to properly participate in the process.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] phpenmod/phpdismod

[Markus Fischer]

Hi,

On 04.02.19 07:24, Remi Collet wrote:

Le 02/02/2019 à 20:24, Legale Legage a écrit :

These scripts are included to the standard deb/rpm packages


No, this is a deb only stuff

RPM installed = extension enabled.


Remi


P.S. I have never understand the need of such tools...
did it made sense in previous century, where download have a cost ?


I find them mostly useful when developing and sometimes useful when in 
production to not have to navigate around the filesystem how to 
enable/disable.


Need ensure my unit tests don't accidentally use redis? `phpdismod 
redis` and done. For all installed PHP versions (maybe due to using the 
popule Ondrey packages though).


Temporarily disble opcache in production because I suspect an issue with 
it? `phpdismod opcache`, reload FPM and done. Don't have to remember 
which exact directory/file which is like 
`/etc/php/./mods-available/ .


That said, it seems really distribution specific to me too.

- Markus

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

Re: [PHP-DEV][RFC] Allow void return type variance

[Claude Pache]

> Le 4 févr. 2019 à 04:22, Wes  a écrit :
> 
> Hello PHPeeps!
> 
> Recent events convinced me to write this RFC :P
> 
> Please have a read here https://wiki.php.net/rfc/allow-void-variance
> 
> I am targeting all the supported PHP versions because this is mainly to
> placate the discontent that arised by PHPUnit enforcing its users to use
> void, so waiting 7.4 doesn't make much sense.
> 
> FTR this is an improvement regardless of PHPUnit, and it's IMO a very
> reasonable change.
> 
> Thank you for your time.
> 
> Wes


The RFC says: “Changing from void to something else is very probably a bad 
idea, but PHP should not enforce void in subclasses just on that basis.” — If 
it is “very probably” a bad idea, why do people want to do that? What are the 
use cases? (Sorry, I’ve not followed the “recent events” you alludes to.)

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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/3/19 9:00 PM, Nikita Popov wrote:
> On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  wrote:
> 
>>
>>> On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
>>>
>>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):


 How is that related?
>>>
>>> It is directly related with your statement that "developers with other
>>> host OSs still use Linux for the actual PHP development". They don't use
>>> Linux for the actual PHP development. They are using Windows.
>>
>> That statement was in a certain context - for those who use containers and
>> Linux VMs, which is (as mentioned) a growing trend.  I think it's clear
>> that I'm not claiming it's everyone, or even the majority - but if it
>> wasn't clear - it should be now...
>>
>> Zeev
>>
> 
> I feel like this discussion ended up going a bit astray, with a focus on
> only the issue of Windows support... While I think that we should endeavor
> to support at least Windows and MacOS before the JIT hits a release version
> of PHP, at this point in time (and for the purposes of the vote) the
> questions of maintenance and stability are the most important.

If we don't start, we definitively won't get support.


> Ultimately
> those questions can't really be answered until interested parties have
> reviewed the JIT codebase. To that end it would be helpful if:
> 
> a) A PR of the JIT branch could be submitted against php-src, so there is a
> place for review comments and more technical discussions. (It might be
> necessary to squash, as GH doesn't deal with large history well.)

OK. Not sure about re-base.

> b) The RFC (or some other place) is extended with some high-level design
> information on how the JIT works on a technical level. Some notes on how
> JIT bugs are usually debugged would also be very helpful.


OK. I'll try to extend RFC with some design elements.

Thanks. Dmitry.

> 
> Regards,
> Nikita
> 

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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/1/19 7:30 PM, Larry Garfield wrote:
> On Friday, February 1, 2019 2:41:06 AM CST Dmitry Stogov wrote:
>> On 2/1/19 3:29 AM, Larry Garfield wrote:
> 
>>> Question from a non-compiler-engineer: Could we end up in a situation
>>> where
>>> future language features (in 8.3 or something) are only performant on JIT-
>>> enabled platforms?  I know there were some RFCs rejected in the past on
>>> the
>>> grounds that they involved too many runtime checks (and thus a performance
>>> hit); if it were possible for a JIT to optimize some of those away, it
>>> might make the cost acceptable.  However, if a JIT only works on some
>>> systems that might widen the gap between have- and have-not platforms.
>>
>> I think, JIT only approach doesn't make a lot of sense for PHP, with one
>> of the most fast VM. And this is a trend. Even V8, starting from JIT
>> only, switched back to VM+JIT.
>>
>> Thanks. Dmitry.
> 
> I'm... not sure how that answers my question?  I'm saying "if we had a VM+JIT,
> and the JIT part made feature X acceptably fast but it wasn't acceptably fast
> with just the VM, is that a problem?"  Or is that a situation that cannot
> happen?  Or that we don't care if it happens?

Everything is possible, but I don't think very realistic now.
When some features are going to depend on JIT, we might have much better 
JIT then now.

Thanks. Dmitry.

> 
> --Larry Garfield
> 

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

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Zeev Suraski]

On Sun, Feb 3, 2019 at 12:08 PM Nikita Popov  wrote:

>
>> Personally, I find any proposal that does not deal with clearly defining
>> voting eligibility not only questionable, but a non-starter, that has no
>> parallels in any other major Open Source projects.
>>
>
> Why? While I think the question of voting eligibility is worth discussing
> (though I also don't consider the problem pressing in any way and think
> that our current pool of voters works quite well, even if it may not be
> what people had in mind back then), it is, just like the question of voting
> margins, a rather independent issue from the remainder of the process.
>

Kris's point made me think about this issue, and I may still need to do
some more thinking about whether the Workflow and Voting elements can be
separated.  It may be that they can.  However, I don't see how the Voting
element can be further separated into "voting eligibility" and "voting
threshold", and other surrounding elements like a quorum which we may want
to introduce.  These are inherently interlinked.  Moreover, there are
elements where even the substance of the given RFC has - or at least
*should* have - influence on the voting margins.  Cases in point:

- The PHP 6 vs PHP 7 naming RFC
- The RFC to determine PHP 7's timeline
- The PHP 5.6 EOL RFC
- Any future RFC about timeline, naming, or other administrative,
non-policy-binding decision

These administrative decisions make no sense to require a 2/3 majority, but
rather - a simple majority of the eligible voters, as ultimately, it's down
to a matter of preference - without any long term (beyond a couple of
years) commitments.

The 2/3 majority was introduced to place a bias-towards-the-status-quo of
the language, and make sure we don't create long-term commitments based on
a temporary narrow majority.  It simply does not apply in such cases.

Further, it's difficult to separate the question of "what requires a vote"
from a statement that "everything requires a 2/3 vote", although
technically not entirely impossible.

I'll do some more thinking about it and consider breaking the Workflow &
Voting into two different RFCs if I can find an elegant way to solve these
issues;  But either way, focusing on the margins alone remains a
non-starter for me.

The problem with bundling together these changes is, if you will excuse the
> political parallel, akin to bundling changes to copyright enforcement
> together with a free trade agreement. Those two things have nothing to do
> with each other (though of course interested parties will argue that they
> are inseparable), but combining them into a single agreement makes it
> feasible to pass changes that would not otherwise be considered acceptable.
> At the same time, it also puts the overall agreement at the danger of
> failing, due to parts that are not related to its core purpose.
>

As demonstrated above, they actually have a lot to do with each other, and
do have certain inter-dependencies.  Thankfully, in our world, neither is a
series of books with countless chapters like free trade and copyright law
tend to be.  I realize that there are some people here that want to simply
focus on the 2/3 margin issue and call it a day, but to me it remains a
very partial fix to a much bigger problem - that realistically, if we don't
tackle now while we've got people's attention - we'll likely never tackle.

The suggestion that the new RFC makes life more difficult, compared to the
>> current Voting RFC, is simply wrong.  It is, in fact, very much the same -
>> except it's a lot more well defined in terms of 'what happens if' - which
>> in the years since the 2011 Voting RFC was enacted became a de-facto
>> wild-west.
>>
>
> As quite likely the single largest user of the RFC process, I beg to
> differ. I think your perspective here comes about, because your use of the
> RFC process is limited to rare, but large (in the sense of important)
> proposals. However, that's not the case for all or even most RFCs. It is
> already the case that RFCs are cumbersome for smaller changes, and all
> active contributors I know (apart from cmb maybe) will go out of their way
> to avoid going through the RFC process if it is at all avoidable. It is
> something of a social faux pas to tell another core contributor on a PR
> that their change might benefit from an RFC, because that generally means
> that the change will be dropped dead in the water instead.
>
> I think that we *should* encourage the use of RFCs for less significant
> changes, because it is useful to have design considerations spelled out in
> more detail than a two line commit message. Your proposal does not make
> things much more complicated, and doesn't make the RFC process take much
> more time. But it increases the marginal costs just enough to make RFCs
> even more annoying than they already are. You edit your proposal a few
> times at inopportune moments and bam, you have to wait one and a half
> months before it can land. Tha

Re: [PHP-DEV] phpenmod/phpdismod

[Remi Collet]

Hi,

Le 02/02/2019 à 20:24, Legale Legage a écrit :
> These scripts are included to the standard deb/rpm packages

No, this is a deb only stuff

RPM installed = extension enabled.


Remi


P.S. I have never understand the need of such tools...
did it made sense in previous century, where download have a cost ?

BTW, on package linux distro, when I install a webapp which depends on
some extensions, I obviously expect than everything needed is enabled...



signature.asc
Description: OpenPGP digital signature

[PHP-DEV] Re: [PHP-WEBMASTER] Re: [PHP-DEV] New website for the PHP project

[Peter Kokot]

Hello,

On Mon, 4 Feb 2019 at 02:03, Levi Morrison  wrote:
>
> On Sun, Feb 3, 2019 at 5:15 PM azjezz  wrote:
> >
> > Hello Internals !
> >
> > As @official_php suggested [1], I'm here to propose a new website for the 
> > PHP Project.
> >
> > In my opinion, current design looks old, outdated and bland. This sadly may 
> > reflect "badly" on the language
> >
> > reputation nowadays.
> >
> > New comers find it hard to go around the website, to write "comments", 
> > report issues or write RFCs.
> >
> > Even signing up for the internals mailing list wasn't an easy task [2].
> >
> > Since the development of PHP 8.0 has started, I think its a good idea to 
> > start working on a new website.
> >
> > # Global proposal
> >
> > The proposal here is to do a major rewrite of the PHP sites. This rewrite 
> > would includes php.net, windows.php.net,
> >
> > bug.php.net, wiki.php.net, qa.php.net and other official php websites.
> >
> > It would be done with this in mind:
> >
> > * No PHP framework (to avoid favoriting one)
> >
> > * Keep it simple: little to no changes to the database structures
> >
> > * This site should look modern, simple and feel welcoming.
> >
> > * A new home page, not a "news" page, but a page simply showing the PHP 
> > Logo, a code example maybe and
> >
> > the download link [3].
> >
> > * A new community website [4], it can be a place for people to ask 
> > questions and discuss php in general - no one uses IRC anymore.
> >
> > * Single account: Users should be able to use the same community account to 
> > file bugs, create a new RFC (depending on karma) and leave notes on the 
> > documentation.
> >
> > * Ideally all *.php.net websites would be "merged" into a single brand new 
> > website, but I'm not sure about the hosting
> >
> > specificities (eg, what server does what).
> >
> > # FrontEnd Framework
> >
> > We don't need that too, but we can use one ! there's some light-weight 
> > options out there.
> >
> > but i'm pretty sure some people in the php community have experience with 
> > front-end development and will happily contribute.
> >
> > see :
> >
> > - https://mustard-ui.com/
> >
> > - https://getuikit.com/
> >
> > - https://bulma.io/
> >
> > - https://picturepan2.github.io/spectre/index.html
> >
> > # Next steps
> >
> > I would really like to hear opinions about this proposal.
> >
> > [1] https://twitter.com/official_php/status/1091903415377108994
> >
> > [2] https://twitter.com/SaraMG/status/1092185205572542466
> >
> > [3] 
> > https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
> >
> > [4] https://php.net/community
> >
> > ---
> >
> > Saif Eddin Gmati 
>
> I appreciate the enthusiasm. If you think the current PHP website is
> old, out-dated, and bland, you must have not experienced the previous
> one:
>
>   https://i2.wp.com/www.geekgumbo.com/wp-content/uploads/2012/01/phpsite45.png
>
> In any case, I hope you realize this is an ambitious project. It will
> take a very long time to build a cohesive UI, and then also a very
> long time to update the bugs, windows, docs, wiki, etc, websites to
> use it. If you are seriously committed to this, then the next step is
> to create mock-ups for every type of page across PHP.net that you can
> find, and to share them on the PHP Webmasters mailing list (which I've
> cc'd). Then, we'll probably give you a few more pages that needs
> mocks, after which you will then have to attempt to build the mock-ups
> in a few different codebases.
>
> I did the last redesign, and I took a less rigorous approach. If I
> were to do it again, I would be much more rigorous in gathering
> requirements and building mock-ups. There were a lot of pages which
> needed re-worked because of my design, which took even more time.
> While it's okay for some pages to be re-worked content-wise to fit the
> new design, you want to minimize it.
>
> --
> PHP Webmaster List Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello, yes, let's do it. I think we must. Thanks for bumping this
topic... Considering that Levi already did such a step once, he knows
a lot what this means and where will be main issues so he can help a
lot here with some advices and all.

>From what I've learned so far with the PHP sites: The websites overall
are very different from one another and some are actually very
complex. The pecl.php.net, bugs.php.net, and the main php.net site are
probably the most complex ones and all written in PHP vanilla way.
After long discussions (regarding the bugs.php.net site), pecl and
bugs sites now include optional Composer for local installation of
some dependencies such as PHPunit, generating fixtures, etc. (not on
production but for local development). So, they are actually going in
the direction of a more modern development. There are also some parts
of php sites that aren't available on GitHub and can't 

[PHP-DEV][RFC] Allow void return type variance

[Wes]

Hello PHPeeps!

Recent events convinced me to write this RFC :P

Please have a read here https://wiki.php.net/rfc/allow-void-variance

I am targeting all the supported PHP versions because this is mainly to
placate the discontent that arised by PHPUnit enforcing its users to use
void, so waiting 7.4 doesn't make much sense.

FTR this is an improvement regardless of PHPUnit, and it's IMO a very
reasonable change.

Thank you for your time.

Wes

Re: [PHP-DEV] Simplify license headers

[Peter Kokot]

On Wed, 30 Jan 2019 at 13:57, Derick Rethans  wrote:
>
> On Mon, 28 Jan 2019, Zeev Suraski wrote:
>
> >
> > > I would like to make two changes to this header:
> > >
> > > 1. Change "PHP Version 7" line to just "PHP", to avoid the necessity of 
> > > updating this for
> > > new major versions. I don't think the version information here is 
> > > particularly useful to
> > > anybody.
> >
> > I don't mind that much, but I don't see any issue with keeping it the way 
> > it is either.  It does look nicer the way it is now IMHO, and the cost 
> > associated with changing it twice a decade is, well, not very substantial.
> >
> > > 2. Remove the "Copyright (c) 1997-2018 The PHP Group" line. Apart from 
> > > requiring a
> > > yearly update, this line is actually complete misinformation, because the 
> > > PHP group
> > > does *not* hold the copyright for the PHP source code. This would require 
> > > a copyright
> > > assignment agreement on behalf of all contributors, which we do not 
> > > collect.
> > >
> > > We could also just drop the header entirely, I'm just proposing these two 
> > > changes as
> > > the path of least resistance towards getting the "annoying" parts removed.
> >
> > I'm no lawyer, but I do believe a case can be made for claiming that a
> > person putting code into files with the header 'Copyright (c) XYZ', is
> > in fact implicitly assigning copyright to XYZ.  So while it's not as
> > strong as an explicit copyright assignment, and while it was never
> > tested in court (and hopefully never will be) - I do see value in
> > keeping it.  I certainly don't see a reason to change it after 20
> > years where it didn't seem to bother anybody, unless there's a strong
> > reason to do that, which currently I don't see.
>
> It could be changed to "1997-present" though, in which case it doesn't
> need updating once a year (and messing up history in VCS).
>
> cheers,
> Derick
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

I've prepared quick pull request [1] that fixes the missed headers in
source code files and additionally bumps or changes the year range on
other places.

Questions:

1.) What should "php -v" output regarding copyrights and year ranges?
2.) What should "man php" include under the COPYRIGHT section
regarding the year ranges?
3.) Similarly, should there be a common pattern for places like
phpinfo() output?

Thanks.

[1] https://github.com/php/php-src/pull/3791

-- 
Peter Kokot

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

Re: [PHP-DEV] New website for the PHP project

[Levi Morrison]

On Sun, Feb 3, 2019 at 5:15 PM azjezz  wrote:
>
> Hello Internals !
>
> As @official_php suggested [1], I'm here to propose a new website for the PHP 
> Project.
>
> In my opinion, current design looks old, outdated and bland. This sadly may 
> reflect "badly" on the language
>
> reputation nowadays.
>
> New comers find it hard to go around the website, to write "comments", report 
> issues or write RFCs.
>
> Even signing up for the internals mailing list wasn't an easy task [2].
>
> Since the development of PHP 8.0 has started, I think its a good idea to 
> start working on a new website.
>
> # Global proposal
>
> The proposal here is to do a major rewrite of the PHP sites. This rewrite 
> would includes php.net, windows.php.net,
>
> bug.php.net, wiki.php.net, qa.php.net and other official php websites.
>
> It would be done with this in mind:
>
> * No PHP framework (to avoid favoriting one)
>
> * Keep it simple: little to no changes to the database structures
>
> * This site should look modern, simple and feel welcoming.
>
> * A new home page, not a "news" page, but a page simply showing the PHP Logo, 
> a code example maybe and
>
> the download link [3].
>
> * A new community website [4], it can be a place for people to ask questions 
> and discuss php in general - no one uses IRC anymore.
>
> * Single account: Users should be able to use the same community account to 
> file bugs, create a new RFC (depending on karma) and leave notes on the 
> documentation.
>
> * Ideally all *.php.net websites would be "merged" into a single brand new 
> website, but I'm not sure about the hosting
>
> specificities (eg, what server does what).
>
> # FrontEnd Framework
>
> We don't need that too, but we can use one ! there's some light-weight 
> options out there.
>
> but i'm pretty sure some people in the php community have experience with 
> front-end development and will happily contribute.
>
> see :
>
> - https://mustard-ui.com/
>
> - https://getuikit.com/
>
> - https://bulma.io/
>
> - https://picturepan2.github.io/spectre/index.html
>
> # Next steps
>
> I would really like to hear opinions about this proposal.
>
> [1] https://twitter.com/official_php/status/1091903415377108994
>
> [2] https://twitter.com/SaraMG/status/1092185205572542466
>
> [3] 
> https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67
>
> [4] https://php.net/community
>
> ---
>
> Saif Eddin Gmati 

I appreciate the enthusiasm. If you think the current PHP website is
old, out-dated, and bland, you must have not experienced the previous
one:

  https://i2.wp.com/www.geekgumbo.com/wp-content/uploads/2012/01/phpsite45.png

In any case, I hope you realize this is an ambitious project. It will
take a very long time to build a cohesive UI, and then also a very
long time to update the bugs, windows, docs, wiki, etc, websites to
use it. If you are seriously committed to this, then the next step is
to create mock-ups for every type of page across PHP.net that you can
find, and to share them on the PHP Webmasters mailing list (which I've
cc'd). Then, we'll probably give you a few more pages that needs
mocks, after which you will then have to attempt to build the mock-ups
in a few different codebases.

I did the last redesign, and I took a less rigorous approach. If I
were to do it again, I would be much more rigorous in gathering
requirements and building mock-ups. There were a lot of pages which
needed re-worked because of my design, which took even more time.
While it's okay for some pages to be re-worked content-wise to fit the
new design, you want to minimize it.

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

[PHP-DEV] New website for the PHP project

[azjezz]

Hello Internals !

As @official_php suggested [1], I'm here to propose a new website for the PHP 
Project.

In my opinion, current design looks old, outdated and bland. This sadly may 
reflect "badly" on the language

reputation nowadays.

New comers find it hard to go around the website, to write "comments", report 
issues or write RFCs.

Even signing up for the internals mailing list wasn't an easy task [2].

Since the development of PHP 8.0 has started, I think its a good idea to start 
working on a new website.

# Global proposal

The proposal here is to do a major rewrite of the PHP sites. This rewrite would 
includes php.net, windows.php.net,

bug.php.net, wiki.php.net, qa.php.net and other official php websites.

It would be done with this in mind:

* No PHP framework (to avoid favoriting one)

* Keep it simple: little to no changes to the database structures

* This site should look modern, simple and feel welcoming.

* A new home page, not a "news" page, but a page simply showing the PHP Logo, a 
code example maybe and

the download link [3].

* A new community website [4], it can be a place for people to ask questions 
and discuss php in general - no one uses IRC anymore.

* Single account: Users should be able to use the same community account to 
file bugs, create a new RFC (depending on karma) and leave notes on the 
documentation.

* Ideally all *.php.net websites would be "merged" into a single brand new 
website, but I'm not sure about the hosting

specificities (eg, what server does what).

# FrontEnd Framework

We don't need that too, but we can use one ! there's some light-weight options 
out there.

but i'm pretty sure some people in the php community have experience with 
front-end development and will happily contribute.

see :

- https://mustard-ui.com/

- https://getuikit.com/

- https://bulma.io/

- https://picturepan2.github.io/spectre/index.html

# Next steps

I would really like to hear opinions about this proposal.

[1] https://twitter.com/official_php/status/1091903415377108994

[2] https://twitter.com/SaraMG/status/1092185205572542466

[3] 
https://camo.githubusercontent.com/762e5d9fcaaa4ecf645343350a91929f99f452e9/68747470733a2f2f692e696d6775722e636f6d2f584477675261662e706e67

[4] https://php.net/community

---

Saif Eddin Gmati 

Re: [PHP-DEV] PHP 8: Method Overloading, The Ressurection

[Dan Ackroyd]

On Sun, 3 Feb 2019 at 18:39, David Rodrigues  wrote:
>
> Hello everybody!
>
> The biggest problem that I see about this topic is the loss of performance,

Although performance impact might be a problem, my impression is that
PHP has some  problems supporting method overloading that don't exist
in other languages.

> So, what other languages does in cases like
> that? Java, for instance.

Java doesn't have type-juggling so they avoid quite a few problems
with dynamic types.

Marcos Passos wrote:

> Java, for instance, throw a compile-time error saying that the
> method signature is ambiguous.

Java compiles all the code in a program before running it, which makes
that solution possible. PHP doesn't and so has to make some decisions
at run-time.


As Christoph wrote:

> overload function sum(int $a, int $b): int;
> overload function sum(float $b, float $b): float;
>
> > Which function would sum(17.4, 42) call?

That's the fundamental problem that would need addressing.

I believe that to have a chance of passing, any method overloading RFC
would need to have a really comprehensive answer that covers all of
the edge cases.

But in addition to that, a really strong argument for why method
overloading is a good thing needs to be made as well, particularly as
the equivalent behaviour can be done in userland*.

btw It is possible, that the thing mostly likely to happen, and
provide the most benefit for you, would be support in your IDE for
autocompletion as implemented in userland. Which might take a lot less
effort than implmenting the feature in PHP core...

cheers
Dan
Ack


* userland implementation:

/**
 * @method sum(int $a, int $b): int;
 * @method sum(float $b, float $b): float;
 */
class Foo
{
public function __call($name, $arguments)
{
if ($name === 'sum' && is_int($arguments[0]) && is_int($arguments[1])) {
return $this->sumInts($arguments[0], $arguments[1]);
}
if ($name === 'sum' && is_float($arguments[0]) &&
is_float($arguments[1])) {
return $this->sumFloats($arguments[0], $arguments[1]);
}
throw new \InvalidArgumentException("Don't know how to call this");
}

private function sumInts(int $a, int $b): int
{
// echo "sumInts was called.\n";
return $a + $b;
}

private function sumFloats(int $a, int $b): int
{
// echo "sumFloats was called.\n";
return $a + $b;
}
}


$foo = new Foo();

$foo->sum(4, 4);
$foo->sum(4.1, 4.1);

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

Re: [PHP-DEV] Re: RFC Weakrefs

[Christoph M. Becker]

On 03.02.2019 at 20:05, Peter Kokot wrote:

> On Sun, 3 Feb 2019 at 20:00, Joe Watkins  wrote:
>>
>> On a side note, at what point do we remove stuff from the manual/pecl, the
>> weakref is extension is dead, can't work with current versions of PHP, and
>> there was never a stable release ?
>>
>> I'm not even sure we have a mechanism to delete stuff from pecl ... there's
>> probably quite a lot of junk on there ...
> 
> Since PECL extensions is one whole compilation of extensions working
> "together" and not falling into conflicts with names and similar
> issues, PECL admins can simply set the package as "superseded by"
> another package. For example:
> https://pecl.php.net/package/date_time
> 
> If another "weakref" PHP extension will be developed elsewhere,
> different naming can be picked for PECL or if that extension will
> return to development, different approaches should be done probably
> for it...

Not sure about removal from the PHP manual.  This may never have
happened before (except for PECL/idn which conflicted with ext/intl).
Might be better to discuss this on the doc mailing list.

F'up2 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Re: PHP 8: Method Overloading, The Ressurection

[Cees-Jan Kiewiet]

Well there should be a:

overload function sum(float $b, float $b): float;

in that case or throw an error for no matching function available imho.

On Sun, Feb 3, 2019 at 8:00 PM Christoph M. Becker 
wrote:

> On 03.02.2019 at 19:39, David Rodrigues wrote:
>
> > overload function sum(int $a, int $b): int;
> > overload function sum(float $b, float $b): float;
>
> Which function would sum(17.4, 42) call?  Also consider:
>
>   sum(PHP_INT_MAX, PHP_INT_MAX)
>
> vs.
>
>   sum(PHP_INT_MAX+1, PHP_INT_MAX+1)
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 

Website

 | Blog

|
Github  | Linkedin
 | Twitter
 | Facebook

Re: [PHP-DEV] Re: PHP 8: Method Overloading, The Ressurection

[Marcos Passos]

I believe we can adopt the behaviour of mature languages that supports this
feature. Java, for instance, throw a compile-time error saying that the
method signature is ambiguous.

On Sun, Feb 3, 2019 at 17:51 David Rodrigues  wrote:

> Em dom, 3 de fev de 2019 às 17:19, Rowan Collins 
> escreveu:
>
> > On 03/02/2019 19:00, Christoph M. Becker wrote:
> > > On 03.02.2019 at 19:39, David Rodrigues wrote:
> > >
> > >> overload function sum(int $a, int $b): int;
> > >> overload function sum(float $b, float $b): float;
> > > Which function would sum(17.4, 42) call?  Also consider:
> > >
> > >sum(PHP_INT_MAX, PHP_INT_MAX)
> > >
> > > vs.
> > >
> > >sum(PHP_INT_MAX+1, PHP_INT_MAX+1)
> >
> >
> > Yes, marking overloaded functions explicitly definitely helps, but I
> > think the dispatch part is more complex than it first seems. Classes and
> > interfaces require a bit of subtlety too:
> >
> > class Foo {}
> > class Bar extends Foo {}
> >
> > overload function foo(Foo $a, Foo $b);
> > overload function foo(Foo $a, Bar $b);
> > overload function foo(Bar $a, Foo $b);
> >
> > foo(new Bar, new Bar);
> >
>
> This example could be complex. So, what other languages does in cases like
> that? Java, for instance.
>
>
> >
> > There are plenty of cases more complex than this, e.g. when a class
> > implements multiple interfaces, and you need to find a matching
> signature.
> >
> > That's not to say it's impossible, just don't underestimate the edge
> > cases you'll need to legislate for.
> >
> > Oh, and note that return types can't participate in overloading, because
> > there's no concept of "desired type" to choose between them.
> >
>
> You are right, in general. But still is possible identify the desired type
> if return is used as argument to a typed parameter, but I still thinks that
> it could not be done in general terms, so maybe we should not includes
> return type to overloading.
>
>
> >
> > Regards,
> >
> > --
> > Rowan Collins
> > [IMSoP]
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
> --
> David Rodrigues
>

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Dan Ackroyd]

On Sat, 2 Feb 2019 at 16:24, Nikita Popov  wrote:
>
> What do you think?

> All RFCs must have a voting period of at least 14 days, announced in a
> separate [VOTE] thread.

That sounds mostly good to me. My feedback would be:

First, I wish people (including RFC authors) took more time to think
about other people's feedback before replying.

There have been some discussions around RFCs where people appear to be
sending email responses within minutes of receiving them, which gives
the appearance of not carefully evaluating that feedback, and trying
to dominate a conversation through volume.

Without a required discussion period, there could be slightly more
'incentive' for RFC authors to respond as quickly as possible, to 'get
the discussion out the way'.

I can't think of a way to codify rules against this behaviour. But
perhaps it could be noted in an updated RFC document something like
"to allow careful consideration, discussions should be allowed to take
time to resolve. It is more appropriate to send a carefully considered
response the next day, than to send a quick response."


Second, two weeks minimum is still quite short.

This may astound people, but I often go weeks at a time without
wondering what is happening in PHP internals. I believe other people
might also have a life outside of PHP internals.

It should be made really clear to people raising RFCs, that choosing
to have the minimum voting time, particularly if the discussion didn't
seem to produce a clear consensus can be, and possibly should be,
interpreted by voters as a reason to vote against an RFC.

cheers
Dan
Ack

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

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Dan Ackroyd]

On Sun, 3 Feb 2019 at 06:19, Zeev Suraski  wrote:
>
> On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd  wrote:
>> Hi Zeev,
>>
>> Please can you very clearly state what problem you are trying to solve
>> by changing the rules about who can vote.
>
> Fair enough, I've heard that question from several others.

I've read all 1200 words of your reply, which is quite a few words.

I still can't see a clear description of what problem you're trying to
solve by changing who can vote.

The reason I'm being pedantic about this, is that when people just
discuss possible solutions to a vague sense of "this situation isn't
perfect", they will often suggest things that don't actually address
the underlying problem. Or disagree about details that don't actually
matter.

We really can't have a clear conversation about what to change without
a clear description of the problem that ought to be solved.

For example, if the fundamental problem you are trying to address is
that it's too difficult for people to get a vote, then I would support
documenting what our current system is, and allowing people to know
what they need to do to acquire a vote. If the fundamental problem the
RFC is trying to address, is to bring in a whole load of new voters,
who don't know how PHP works internally, then I wouldn't be as
supportive.

cheers
Dan
Ack

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

Re: [PHP-DEV] Re: PHP 8: Method Overloading, The Ressurection

[David Rodrigues]

Em dom, 3 de fev de 2019 às 17:19, Rowan Collins 
escreveu:

> On 03/02/2019 19:00, Christoph M. Becker wrote:
> > On 03.02.2019 at 19:39, David Rodrigues wrote:
> >
> >> overload function sum(int $a, int $b): int;
> >> overload function sum(float $b, float $b): float;
> > Which function would sum(17.4, 42) call?  Also consider:
> >
> >sum(PHP_INT_MAX, PHP_INT_MAX)
> >
> > vs.
> >
> >sum(PHP_INT_MAX+1, PHP_INT_MAX+1)
>
>
> Yes, marking overloaded functions explicitly definitely helps, but I
> think the dispatch part is more complex than it first seems. Classes and
> interfaces require a bit of subtlety too:
>
> class Foo {}
> class Bar extends Foo {}
>
> overload function foo(Foo $a, Foo $b);
> overload function foo(Foo $a, Bar $b);
> overload function foo(Bar $a, Foo $b);
>
> foo(new Bar, new Bar);
>

This example could be complex. So, what other languages does in cases like
that? Java, for instance.


>
> There are plenty of cases more complex than this, e.g. when a class
> implements multiple interfaces, and you need to find a matching signature.
>
> That's not to say it's impossible, just don't underestimate the edge
> cases you'll need to legislate for.
>
> Oh, and note that return types can't participate in overloading, because
> there's no concept of "desired type" to choose between them.
>

You are right, in general. But still is possible identify the desired type
if return is used as argument to a typed parameter, but I still thinks that
it could not be done in general terms, so maybe we should not includes
return type to overloading.


>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
David Rodrigues

Re: [PHP-DEV] Re: PHP 8: Method Overloading, The Ressurection

[Rowan Collins]

On 03/02/2019 19:00, Christoph M. Becker wrote:

On 03.02.2019 at 19:39, David Rodrigues wrote:


overload function sum(int $a, int $b): int;
overload function sum(float $b, float $b): float;

Which function would sum(17.4, 42) call?  Also consider:

   sum(PHP_INT_MAX, PHP_INT_MAX)

vs.

   sum(PHP_INT_MAX+1, PHP_INT_MAX+1)



Yes, marking overloaded functions explicitly definitely helps, but I 
think the dispatch part is more complex than it first seems. Classes and 
interfaces require a bit of subtlety too:


class Foo {}
class Bar extends Foo {}

overload function foo(Foo $a, Foo $b);
overload function foo(Foo $a, Bar $b);
overload function foo(Bar $a, Foo $b);

foo(new Bar, new Bar);

There are plenty of cases more complex than this, e.g. when a class 
implements multiple interfaces, and you need to find a matching signature.


That's not to say it's impossible, just don't underestimate the edge 
cases you'll need to legislate for.


Oh, and note that return types can't participate in overloading, because 
there's no concept of "desired type" to choose between them.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Re: RFC Weakrefs

[Peter Kokot]

Hello,

On Sun, 3 Feb 2019 at 20:00, Joe Watkins  wrote:
>
> Already taken care of :)
>
> On a side note, at what point do we remove stuff from the manual/pecl, the
> weakref is extension is dead, can't work with current versions of PHP, and
> there was never a stable release ?
>
> I'm not even sure we have a mechanism to delete stuff from pecl ... there's
> probably quite a lot of junk on there ...
>

Since PECL extensions is one whole compilation of extensions working
"together" and not falling into conflicts with names and similar
issues, PECL admins can simply set the package as "superseded by"
another package. For example:
https://pecl.php.net/package/date_time

If another "weakref" PHP extension will be developed elsewhere,
different naming can be picked for PECL or if that extension will
return to development, different approaches should be done probably
for it...

-- 
Peter Kokot

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

Re: [PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Already taken care of :)

On a side note, at what point do we remove stuff from the manual/pecl, the
weakref is extension is dead, can't work with current versions of PHP, and
there was never a stable release ?

I'm not even sure we have a mechanism to delete stuff from pecl ... there's
probably quite a lot of junk on there ...

Cheers
Joe

On Sun, 3 Feb 2019 at 19:56, Christoph M. Becker  wrote:

> On 03.02.2019 at 19:39, Joe Watkins wrote:
>
> > Does that solve the problem for you Christoph ?
>
> Yes, calling the class WeakReference would be fine for me.
>
> --
> Christoph M. Becker
>

[PHP-DEV] Re: PHP 8: Method Overloading, The Ressurection

[Christoph M. Becker]

On 03.02.2019 at 19:39, David Rodrigues wrote:

> overload function sum(int $a, int $b): int;
> overload function sum(float $b, float $b): float;

Which function would sum(17.4, 42) call?  Also consider:

  sum(PHP_INT_MAX, PHP_INT_MAX)

vs.

  sum(PHP_INT_MAX+1, PHP_INT_MAX+1)

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Re: RFC Weakrefs

[Christoph M. Becker]

On 03.02.2019 at 19:39, Joe Watkins wrote:

> Does that solve the problem for you Christoph ?

Yes, calling the class WeakReference would be fine for me.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Updated patch, name is WeakReference.

Cheers
Joe

On Sun, 3 Feb 2019 at 19:39, Joe Watkins  wrote:

> Does that solve the problem for you Christoph ?
>
> Cheers
> Joe
>
> On Sun, 3 Feb 2019 at 19:08, Robert Korulczyk  wrote:
>
>>
>> > I can't really think of another name ... it's ... a weakref ...
>>
>> It is actually "weak reference", so why not WeakReference?
>>
>>
>> Regards,
>> Robert Korulczyk
>>
>

Re: [PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Does that solve the problem for you Christoph ?

Cheers
Joe

On Sun, 3 Feb 2019 at 19:08, Robert Korulczyk  wrote:

>
> > I can't really think of another name ... it's ... a weakref ...
>
> It is actually "weak reference", so why not WeakReference?
>
>
> Regards,
> Robert Korulczyk
>

[PHP-DEV] PHP 8: Method Overloading, The Ressurection

[David Rodrigues]

Hello everybody!

I know that method overloading was discussed on past and because a lot of
reasons it was declined [1]. I think that it should be considered maybe for
PHP 8, but for now I would like to suggest a different implementation.

Because of a stronger support to parameter types that PHP has now, I think
that is possible make this process more faster than before by handling it
only in case of exceptions. I wil explain better.

The biggest problem that I see about this topic is the loss of performance,
but I think that it could be avoided by create a new keyword "overload"
that should be applied before methods that could be overloaded. For
instance:

overload function sum(int $a, int $b): int;
overload function sum(float $b, float $b): float;

In this case, when call a method PHP could identify if it have a overloaded
implementation, so ONLY in this case it will reduce performace to decided
which implementation it should call.

I don't know how PHP could treats it internally, but when overload keyword
is identified, I think that it could generates a hash like
"sum/int,int/int" and "sum/float,float/float" (method name, parameters
types, return type). I don't know. So when method is called, it should
convert the argument types and create a similar hash, making possible to
identify what overloaded method should be run. It seems slow, but I think
that the opcache could simplify the next operations to connect directly the
call to the correct overloaded method.

Please, tell what do you think, because I really wants method overload on
PHP 8 or before. Currently we should do some code hacks to make it possible
that certainly is slower than a native implementation.

Thanks!

 [1] https://marc.info/?l=php-internals&m=121397217528280&w=2

-- 
David Rodrigues

Re: [PHP-DEV] Re: RFC Weakrefs

[Robert Korulczyk]

> I can't really think of another name ... it's ... a weakref ...

It is actually "weak reference", so why not WeakReference?


Regards,
Robert Korulczyk

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

Re: [PHP-DEV] [RFC] JIT

[Andrey Hristov]

 Guys,
On 3.02.19 г. 18:16 ч., Zeev Suraski wrote:



On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:

Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):



How is that related?


It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.


That statement was in a certain context - for those who use containers and 
Linux VMs, which is (as mentioned) a growing trend.  I think it's clear that 
I'm not claiming it's everyone, or even the majority - but if it wasn't clear - 
it should be now...


please correct me but Docker containers can be run with Hyper-V 
isolation on recent Windows versions. This way the users of of these 
recent Windows versions can get directly the Linux performance jump.


And also, whoever hasn't started using containers while developing with 
PHP should start doing so and not to rely on *AMP tools for packaging.


Andrey


Zeev




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

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  wrote:

>
> > On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
> >
> > Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
> >>
> >>
> >> How is that related?
> >
> > It is directly related with your statement that "developers with other
> > host OSs still use Linux for the actual PHP development". They don't use
> > Linux for the actual PHP development. They are using Windows.
>
> That statement was in a certain context - for those who use containers and
> Linux VMs, which is (as mentioned) a growing trend.  I think it's clear
> that I'm not claiming it's everyone, or even the majority - but if it
> wasn't clear - it should be now...
>
> Zeev
>

I feel like this discussion ended up going a bit astray, with a focus on
only the issue of Windows support... While I think that we should endeavor
to support at least Windows and MacOS before the JIT hits a release version
of PHP, at this point in time (and for the purposes of the vote) the
questions of maintenance and stability are the most important. Ultimately
those questions can't really be answered until interested parties have
reviewed the JIT codebase. To that end it would be helpful if:

a) A PR of the JIT branch could be submitted against php-src, so there is a
place for review comments and more technical discussions. (It might be
necessary to squash, as GH doesn't deal with large history well.)

b) The RFC (or some other place) is extended with some high-level design
information on how the JIT works on a technical level. Some notes on how
JIT bugs are usually debugged would also be very helpful.

Regards,
Nikita

[PHP-DEV] Re: RFC Weakrefs

[Joe Watkins]

Afternoon Christoph,

I can't really think of another name ... it's ... a weakref ...

Probably using the PHP namespace makes most sense.

Cheers
Joe

On Sun, 3 Feb 2019 at 18:40, Christoph M. Becker  wrote:

> On 02.02.2019 at 09:35, Joe Watkins wrote:
>
> > Some time ago I brought this up for discussion, and last night was
> reminded
> > of it's existence, and so this morning rebased and reworked the patch a
> > little based on the feedback I got back then.
> >
> > Since it was long ago, and there's no particular rush, I don't intend to
> > open voting until the current policy adjustment RFC's are resolved, but
> > wanted to give everyone a heads up and ask for any feedback you may have
> at
> > this time.
> >
> > https://wiki.php.net/rfc/weakrefs
>
> Overall I like this.  Thanks!
>
> However, calling this class WeakRef would introduce a potential BC
> break, and would be a particular issue regarding the PHP manual, which
> does not allow to document two classes with exactly the same name.
>
> Even if Etienne would officially cease the further development of
> PECL/Weakref[1], having a class with the same name appears to be
> confusing at best.
>
> Maybe another name should be chosen for the class?  Or maybe we should
> finally introduce the \PHP namespace?
>
> [1] 
>
> --
> Christoph M. Becker
>

[PHP-DEV] Re: RFC Weakrefs

[Christoph M. Becker]

On 02.02.2019 at 09:35, Joe Watkins wrote:

> Some time ago I brought this up for discussion, and last night was reminded
> of it's existence, and so this morning rebased and reworked the patch a
> little based on the feedback I got back then.
> 
> Since it was long ago, and there's no particular rush, I don't intend to
> open voting until the current policy adjustment RFC's are resolved, but
> wanted to give everyone a heads up and ask for any feedback you may have at
> this time.
> 
> https://wiki.php.net/rfc/weakrefs

Overall I like this.  Thanks!

However, calling this class WeakRef would introduce a potential BC
break, and would be a particular issue regarding the PHP manual, which
does not allow to document two classes with exactly the same name.

Even if Etienne would officially cease the further development of
PECL/Weakref[1], having a class with the same name appears to be
confusing at best.

Maybe another name should be chosen for the class?  Or maybe we should
finally introduce the \PHP namespace?

[1] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Larry Garfield]

On Friday, February 1, 2019 7:11:40 PM CST Kalle Sommer Nielsen wrote:
> Den fre. 1. feb. 2019 kl. 02.42 skrev Larry Garfield 

> > >  So I would support a mechanism of some sort to give formal voting 
rights
> >  to
> > non-internals-C-developers who are still significant-PHP-contributors, as
> > long as the number of people involved is relatively low compared to the
> > direct- contributor number.  With a contributor voting pool of ~175
> > (which would no doubt vary but let's assume stays in vaguely the same
> > range), an "at large voter" population of 5, 10, or 15 people would
> > provide direct representation without a meaningful risk of swamping the
> > direct contributors, who I agree should remain the overwhelming majority
> > of eligible voters.
> 
> So while you fully agree with its a bad idea that us the Core
> Developers have to maintain code that is decided by external, non
> contributing parties, still you think there should be a way for non
> Core Developers to vote? That is kinda absurd.

It's not absurd, it's a matter of degrees.  As Zeev noted in a later email, 
the current voting RFC already calls for some voting-level input from "major 
customers", but not a controlling vote.

To use hyperbolic examples: 

Would adding one single non-C-developer to the voting rolls mean that "the 
Core Developers have to maintain code that is decided by external, non 
contributing parties"?  No, that's "kinda absurd" to call it that, because 
that one voter is clearly swamped out by  the many other Internals developers 
that are also voting.

Would adding 200 non-C developers to the voting roll mean that?  Certainly 
yes, that would be an absurd situation.  But no one that I've seen is 
suggesting that at all, or anything close to it.

What's the threshold of absurdity here?  That we could debate.  However, it is 
not 0.  (I'd personally put it in the 10-20 range, bearing in mind that not 
all of them would vote all the time anyway, just like core developers, but 
others may feel differently.)


> > This would be the first formal recognition of FIG by PHP Internals.  I am
> > completely OK with that, and personally would love to see Internals and
> > FIG
> > collaborate more; I'm just noting it for completeness.
> 
> I'm not okay with that at all. I accept and respect what you as a
> project do, but because of that it doesn't mean you (you as in a
> project) should have a special right over our project because you
> represent some of the most used userland projects. Besides the very
> high profile projects like Laravel and Symfony (even projects like
> Doctrine and Guzzle) is no longer represented, WordPress is not even a
> part of the FIG.

The degree to which "participation in a big name project" correlates or has a 
causal relationship with "is a significant voice and influencer in the 
community" is a contentious question, and one that FIG has debated for years.  
Without going too far down that rabbit hole I will only say "it's very 
complicated" and not cut and dry either direction.

> Given the volume of people who currently votes on RFCs on average,
> that would literally mean that we would increase our average voting
> pool by 25%, something to consider as by then the FIG would
> essentially sit with about a 20% say in whether or not something
> should go in and their hands will stay clean because we as maintainers
> will have to do the dirty work and that is without projects like
> Laravel, Symfony and WordPress having a say, just the FIG.

To answer both you and Sanislav here together, as he raised a similar point, 
that presumes that 100% of the "invited outsiders" vote on every RFC.  I think 
that is unlikely, although I freely admit I have no real data to speculate 
either way.  Lacking any other evidence I'd say it would probably follow a 
similar pattern to Internals day.  (If we assume a 175 person voting pool and 
a turnout of about 50, then that's in the neighborhood of 25-30%.)  
Truthfully, though, none of us have any idea what the total impact would be.

That same point applies to any "invited outsiders", whether that's done 
through FIG or otherwise.  Per Zeev's email, it does seem like some mechanism 
for invited-outsiders was always intended, even if it never materialized.

> > (Disclosure: I am a member of the Core Committee so that would include me;
> > I hope that doesn't itself turn anyone off of the idea :-), but I mention
> > it for transparency and feel it would be a good approach even if I
> > weren't.)

> That itself worries me, because you are represent a part of the
> community using the language, but you are not a language designer. You
> are active with input on internals and RFCs etc, which I respect a
> lot, but without any interest in actually writing code (I can't really
> say if its true or not regarding the interest or its because of C
> know-how) or because of time schedules like we all have, I don't see
> why a special exception should be granted. No offens

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Larry Garfield]

On Sunday, February 3, 2019 4:07:46 AM CST Nikita Popov wrote:
> On Sun, Feb 3, 2019 at 6:18 AM Zeev Suraski  wrote:

> > The suggestion that the new RFC makes life more difficult, compared to the
> > current Voting RFC, is simply wrong.  It is, in fact, very much the same -
> > except it's a lot more well defined in terms of 'what happens if' - which
> > in the years since the 2011 Voting RFC was enacted became a de-facto
> > wild-west.
> 
> As quite likely the single largest user of the RFC process, I beg to
> differ. I think your perspective here comes about, because your use of the
> RFC process is limited to rare, but large (in the sense of important)
> proposals. However, that's not the case for all or even most RFCs. It is
> already the case that RFCs are cumbersome for smaller changes, and all
> active contributors I know (apart from cmb maybe) will go out of their way
> to avoid going through the RFC process if it is at all avoidable. It is
> something of a social faux pas to tell another core contributor on a PR
> that their change might benefit from an RFC, because that generally means
> that the change will be dropped dead in the water instead.
> 
> I think that we *should* encourage the use of RFCs for less significant
> changes, because it is useful to have design considerations spelled out in
> more detail than a two line commit message. Your proposal does not make
> things much more complicated, and doesn't make the RFC process take much
> more time. But it increases the marginal costs just enough to make RFCs
> even more annoying than they already are. You edit your proposal a few
> times at inopportune moments and bam, you have to wait one and a half
> months before it can land. That's okay if you're trying to introduce a JIT
> in PHP, but if you just want to add a function, that's the point where you
> say "Why do I even bother with this?"
> 
> Regards,
> Nikita

If I may, it seems like the intended goal is to ensure that a proposal gets 
"enough" attention, "enough" time for people with other priorities to find, 
read, digest, and decide on it, and to avoid last minute changes in the RFC so 
that people don't fully realize what they're voting on (for some definition of 
"enough").

To that end, what about simply a "fallow period" before a vote can be called?  
To wit:

"Once an RFC has been announced, the proposal may call a vote on it at any 
time provided that there have been no substantive changes within the past 2 
weeks.  If there is reasonable dispute over whether a change is 'substantive', 
then it is assumed to be substantive."

That assures that there is always at least a 2 week discussion period, but you 
could still go from proposal to vote in 2 weeks.  It also ensures that if 
you've read an RFC in the last 2 weeks when the vote is called that you're 
still up to date.  However, minor changes (wording, revising an argument for 
something but not changing the actual thing, etc.) don't cause an RFC to sit 
in limbo for months.  Of course, if the RFC is still changing regularly then 
that would continue to kick the voting period further down the line, which is 
what you want in that case since it's still being revised.

It also has the advantage of being really short and easy to grok.  

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

> On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
> 
> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
>> 
>> 
>> How is that related?
> 
> It is directly related with your statement that "developers with other
> host OSs still use Linux for the actual PHP development". They don't use
> Linux for the actual PHP development. They are using Windows.

That statement was in a certain context - for those who use containers and 
Linux VMs, which is (as mentioned) a growing trend.  I think it's clear that 
I'm not claiming it's everyone, or even the majority - but if it wasn't clear - 
it should be now...

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

Re: [PHP-DEV] phpenmod/phpdismod

[Lester Caine]

On 03/02/2019 02:44, Walter Parker wrote:

If you can make it work on MacOS, Windows, and the BSDs, then great.
Otherwise, it should be left to the Linux distributions.


And bare in mind that there are a number of different standards 
CURRENTLY used across the different LINUX distributions! The question of 
managing selection of what extensions ARE loaded is a minefield in it's 
own right ... and just where they are loaded by default.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] JIT

[Lester Caine]

On 03/02/2019 06:51, Zeev Suraski wrote:

While this is anecdotal, I think you might find a different perspective from 
user group organizers. I've encountered many user group members over the years 
who run PHP on Windows. It's more common that they develop on Windows and 
deploy to Linux, but I do know those who also deploy to Windows in production.


This is actually very consistent with my experience, including some hard data I 
have from relevant (even if it 100% representative) download and usage stats.  
Windows is an extremely popular platform for developing PHP on - in fact, from 
the data I have (which isn’t conclusive) - it’s even more popular than Linux in 
certain demographics.  But much like you say, this dev scenario is more common 
(I would say a lot more common) than it is to see Windows in production - which 
does not come to say it’s non existent in prod, just that it’s a lot less 
common.



To add to that ... just how many windows based developers have actually 
moved to PHP7? I'd missed that the official windows package HAD dropped 
PEAR, but it's provided as part of the older third party windows 
distributions, and THOSE are the ones being used by the people I'm 
supporting because for a time there were no official distributions on 
windows.. THAT is the reason their code base has not move to PHP7 as it 
does not have access to all the third party packages being used.


While JIT should be totally transparent, is it not the case that 
invariably edge cases can cause different effects on different 
platforms, and it is perhaps that which is creating a concern if code 
can't be fully tested on a windows platform for that reason? In 
practice, it's academic, since if there are subtle differences between 
Linux and Windows it probably does not matter if JIT is enabled or not? 
One or other is simply displaying a bug that needs fixing?


Certainly production wise there is little evidence that W10 has done 
anything to improve the speed of the web stack which still lags far 
behind Linux on the same hardware, bu it's some time since I ACTUALLY 
tested that but perhaps it is time to update my own benchmarks.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] JIT

[Jan Ehrhardt]

Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
>Jan Ehrhardt in php.internals (Sun, 03 Feb 2019 11:47:09 +0100):
>>Hi Zeev,
>>
>>Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
>>>2.  Most PHP production workloads are on Linux, and as far as I can tell
>>>this trend is only growing over the years - with virtual machines and
>>>now containers becoming more and more popular - meaning that even
>>>developers with other host OSs still use Linux for the actual PHP
>>>development.
>>
>>I am not sure this really is the case. Depending on which statistics you
>>believe te be true, about a quarter to a third of the Web is powered by
>>Wordpress. Wordpress market share is not diminishing.
>>
>>Do not underestimate the huge amount of Wordpress plugin developers that
>>develop on Windows. Code quality is varying from very low to quite high,
>>but these people are PHP developers as well.
>
>How is that related?

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.
-- 
Jan

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

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

On 3 Feb 2019, at 12:47, Jan Ehrhardt 
mailto:php...@ehrhardt.nl>> wrote:

Hi Zeev,

Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
2.  Most PHP production workloads are on Linux, and as far as I can tell
this trend is only growing over the years - with virtual machines and
now containers becoming more and more popular - meaning that even
developers with other host OSs still use Linux for the actual PHP
development.

I am not sure this really is the case. Depending on which statistics you
believe te be true, about a quarter to a third of the Web is powered by
Wordpress. Wordpress market share is not diminishing.

How is that related?  The vast majority of WordPress is deployed on Linux 
servers, much (if not most) of it hosted.

Do not underestimate the huge amount of Wordpress plugin developers that
develop on Windows. Code quality is varying from very low to quite high,
but these people are PHP developers as well.

Again, how does that relate to what I said?  I actually said in some 
demographics Windows is more common than Linux *for development*.   I'm also 
saying that's slowly changing due to certain tech trends, but it doesn't mean 
that Windows development isn't still incredibly popular.  The thing is, it's 
mostly orthogonal to JIT - which is a production oriented feature.

Zeev

Re: [PHP-DEV] [RFC] JIT

[Jan Ehrhardt]

Hi Zeev,

Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
>2.  Most PHP production workloads are on Linux, and as far as I can tell
>this trend is only growing over the years - with virtual machines and
>now containers becoming more and more popular - meaning that even
>developers with other host OSs still use Linux for the actual PHP
>development.

I am not sure this really is the case. Depending on which statistics you
believe te be true, about a quarter to a third of the Web is powered by
Wordpress. Wordpress market share is not diminishing.

Do not underestimate the huge amount of Wordpress plugin developers that
develop on Windows. Code quality is varying from very low to quite high,
but these people are PHP developers as well.
-- 
Jan

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

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Nikita Popov]

On Sun, Feb 3, 2019 at 6:18 AM Zeev Suraski  wrote:

>
>
> > -Original Message-
> > From: Nikita Popov 
> > Sent: Saturday, February 2, 2019 6:24 PM
> > To: PHP internals 
> > Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC
> process
> >
> > Hi internals,
> >
> > After discussing the topic with a number of current and former
> contributors, I
> > feel that the workflow & voting RFC currently under discussion is moving
> us in
> > the wrong direction. I will not comment on the rather questionable
> proposed
> > changes to voting eligibility, as these are already extensively
> discussed in the
> > RFC thread.
>
> Personally, I find any proposal that does not deal with clearly defining
> voting eligibility not only questionable, but a non-starter, that has no
> parallels in any other major Open Source projects.
>

Why? While I think the question of voting eligibility is worth discussing
(though I also don't consider the problem pressing in any way and think
that our current pool of voters works quite well, even if it may not be
what people had in mind back then), it is, just like the question of voting
margins, a rather independent issue from the remainder of the process. I
think that these discussions and RFC can and should be split up into the
question of voting margins, the question of voting eligibility and the
question of the RFC procedure itself. While these things are of course
related, they can also be decided independently.

The problem with bundling together these changes is, if you will excuse the
political parallel, akin to bundling changes to copyright enforcement
together with a free trade agreement. Those two things have nothing to do
with each other (though of course interested parties will argue that they
are inseparable), but combining them into a single agreement makes it
feasible to pass changes that would not otherwise be considered acceptable.
At the same time, it also puts the overall agreement at the danger of
failing, due to parts that are not related to its core purpose.

I understand that there is also benefit in deciding related questions in
conjunction, in that a decision in one area would only be acceptable
conditional on a decision in another area. However, to get back to the
specific topic here, this does not appear to be applicable. For example,
your changes to the RFC workflow could be implemented independently of the
voting eligibility changes and vice versa. The only possible dependency I
see is that all proposals benefit from having the 2/3 voting margin as a
baseline (which is consistent with that RFC proceeding first, of course).


> The suggestion that the new RFC makes life more difficult, compared to the
> current Voting RFC, is simply wrong.  It is, in fact, very much the same -
> except it's a lot more well defined in terms of 'what happens if' - which
> in the years since the 2011 Voting RFC was enacted became a de-facto
> wild-west.
>

As quite likely the single largest user of the RFC process, I beg to
differ. I think your perspective here comes about, because your use of the
RFC process is limited to rare, but large (in the sense of important)
proposals. However, that's not the case for all or even most RFCs. It is
already the case that RFCs are cumbersome for smaller changes, and all
active contributors I know (apart from cmb maybe) will go out of their way
to avoid going through the RFC process if it is at all avoidable. It is
something of a social faux pas to tell another core contributor on a PR
that their change might benefit from an RFC, because that generally means
that the change will be dropped dead in the water instead.

I think that we *should* encourage the use of RFCs for less significant
changes, because it is useful to have design considerations spelled out in
more detail than a two line commit message. Your proposal does not make
things much more complicated, and doesn't make the RFC process take much
more time. But it increases the marginal costs just enough to make RFCs
even more annoying than they already are. You edit your proposal a few
times at inopportune moments and bam, you have to wait one and a half
months before it can land. That's okay if you're trying to introduce a JIT
in PHP, but if you just want to add a function, that's the point where you
say "Why do I even bother with this?"

Regards,
Nikita

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Bob Weinand]

> Am 03.02.2019 um 06:18 schrieb Zeev Suraski :
> 
>> -Original Message-
>> From: Nikita Popov 
>> Sent: Saturday, February 2, 2019 6:24 PM
>> To: PHP internals 
>> Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
>> 
>> Hi internals,
>> 
>> After discussing the topic with a number of current and former contributors, 
>> I
>> feel that the workflow & voting RFC currently under discussion is moving us 
>> in
>> the wrong direction. I will not comment on the rather questionable proposed
>> changes to voting eligibility, as these are already extensively discussed in 
>> the
>> RFC thread.
> 
> Personally, I find any proposal that does not deal with clearly defining 
> voting eligibility not only questionable, but a non-starter, that has no 
> parallels in any other major Open Source projects.
> 
> The suggestion that the new RFC makes life more difficult, compared to the 
> current Voting RFC, is simply wrong.  It is, in fact, very much the same - 
> except it's a lot more well defined in terms of 'what happens if' - which in 
> the years since the 2011 Voting RFC was enacted became a de-facto wild-west.
> 
> It may initially feel warm & fuzzy to  have vague, fluid rules that are 
> remarkably open to interpretation.  But it's not a good idea at all.
> 
> Zeev

Hey Zeev,

why is dealing with voting eligibility a requirement for a new RFC dealing with 
the RFC process? Everything which is not dealt with, is simply inherited from 
status quo. And I personally don't think the current rules regarding voting 
eligibility, while possibly not perfect, are in such a bad state that they 
immediately need a rework. The door to concrete, separate proposals fixing 
voting eligibility is not closed with this RFC. You are always free to open a 
new specific RFC and discuss about a voting eligibility proposal.

In addition, the newly proposed RFC here is absolutely not vague. It is pretty 
well defined, showing a few clear boundaries. For everything else it is the 
task of the voter to establish whether a RFC is ready and shall be voted in as 
is. It's precisely that which makes a great voting process. In particular with 
a 2/3 required majority, I strongly doubt that bullshit RFCs which are quickly 
proposed and moved to vote, will ever be accepted. I trust our voters enough to 
know when something should definitely not be accepted.

And I strongly hope that you are not lacking faith in us PHP RFC voters, that 
you feel like you couldn't trust us to apply sensible judgement to each RFC.

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

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

[Kris Craig]

On Sat, Feb 2, 2019 at 10:20 PM Zeev Suraski  wrote:

> On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd  wrote:
>
> > On Thu, 31 Jan 2019 at 13:44, Zeev Suraski  wrote:
> > >
> > > Without further ado, an RFC that’s attempting to comprehensively solve
> > many of the issues that have plagued our RFC process since it was hastily
> > introduced in 2011:
> >
> > Hi Zeev,
> >
> > Please can you very clearly state what problem you are trying to solve
> > by changing the rules about who can vote.
> >
> > Without presenting the problem, and why your solution is the correct
> > one, it's not obvious that the change being proposed is either needed
> > or the right one choice.
> >
>
> Fair enough, I've heard that question from several others.
>
> I'll use your email to clarify my motivation for the RFC, primarily on the
> voting eligibility part - in slightly more detail than my reply to Nikita
> on the other thread.
>
> Beginning with the latter, the reality of things that the Voting RFC of
> 2011 was written in what was supposed to codify, and also structure a bit
> more the already existing process of decision making that we had prior to
> it.  The structuring was mainly through the introduction of a voting
> process, as well as some elements such as a mandatory discussion period.
> However, it quickly became apparent that this RFC, that was written with a
> certain 'working knowledge' of what was already happening de-facto, and
> assuming these would continue - became treated as if it was the U.S.
> constitution, and whatever wasn't in it - did not exist.  Moreover - even
> elements which were in fact in it (such as the voting eligibility), became
> ignored - exclusively for the simple reason of the way the Wiki software,
> used for voting, was implemented.
>
> Edge cases came up over the years in all sorts of manners.  The most recent
> edge case which isn't handled by the terse, laconic 2011 Voting RFC is the
> Abolishing Narrow Margins RFC, which went straight from de-facto
> hibernation into a "we're about to vote" stage overnight.  But there were
> many others (and yes, one of the common ones was 'how do we choose between
> 50%+1 and 2/3', but it was by no means the only one).  The goal here is to
> provide clear cut answers to these cases, instead of leaving it up to the
> RFC author to decide.  Over the years, it became clear that RFC authors had
> not only the ability to decide what goes into the RFC, but to also decide
> much of the process surrounding the discussion and acceptance of the RFC -
> filling the major voids that were present in the terse 2011 Voting RFC on
> demand.
>
> In terms of Voting Eligibility, here's what was written in the original
> RFC:
>
> ---quote---
> There's no way around this 'small' issue. Changes made to the PHP language
> will affect millions of people, and theoretically, each and every one of
> them should have a say in what we do. For obvious reasons, though, this
> isn't a practical approach.
>
> The proposal here is for two audiences to participate in the voting
> process:
>
> - People with php.net VCS accounts that have contributed code to PHP:
> - Representatives from the PHP community, that will be chosen by those with
> php.net VCS accounts
>- Lead developers of PHP based projects (frameworks, cms, tools, etc.)
>- regular participant of internals discussions
> ---end quote---
>
> Now, there are several things you can tell from the way this topic is
> treated that are evident from this text.  First, that the topic of Voting
> Eligibility wasn't taken lightly, nor was there any intention to provide a
> very low bar on who gets to vote.  Secondly, which is a lot more
> unfortunate, it's very terse and laconic - like the rest of the RFC - e.g.,
> when stating how the folks from the the 2nd group of eligible voters will
> be chosen - even though it's evident that the idea was that they *will* be
> chosen, in one way or another;  Heck, even the first group is open to
> interpretation from the way it's written (although the intention was clear)
> - code contributors to PHP - was supposed to mean folks that truly
> contributed code to PHP, and not every person with a VCS account (it's
> clearly a subset, even from the poor way it's written).  Bear in mind that
> Pierre Joye, that promoted this RFC - believed that we will be able to
> figure these parts out as we go along.  De-facto, what happened was very
> different - overnight, because of the way the Wiki software was
> implemented, anybody with a VCS account became an eligible voter, with the
> same weight as Rasmus, myself, Nikita, or whomever else.  This was never
> the intention.
>
> What was the intention?  In a nutshell:
> - Code contributors to php-src get a vote
> - Everyone with a VCS account (wider audience) get the ability to choose
> folks that are beyond the first group, that will also get a vote (with the
> assumption that the number of folks elected in this way will not be nearly
> as high as the numbe