Re: [PHP-DEV] Re: Increase maximum size of an uploaded file to 50Mbyte

[Kris Craig]

On Wed, Sep 7, 2022 at 11:38 AM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:

> I looked for a potential problem out of doing such a change but I could not
> find anything.
>

Then I'd say it's a no-brainer.  The current 2 MB limit is simply outdated
and needs to be increased to something a little more realistic.

That said, I think 50 MB may be pushing it.  How about 20 MB, instead?


>
> But for sure such a change should be well marked in case is merge.
>
> I did not take look at the PR as that can wait also.
>
> Lets respect the RFC protocol and wait the specified time to see if someone
> else comes with something.
>
> By the Way... This needs an RFC right?
>

Yes, most definitely.

Re: [PHP-DEV] Regarding Russia invasion on Ukraine

[Kris Craig]

On Sun, Mar 13, 2022, 1:46 PM Chase Peeler  wrote:

>
> On Sun, Mar 13, 2022 at 4:43 PM Kris Craig  wrote:
>
>> On Sun, Mar 13, 2022, 1:36 PM Larry Garfield 
>> wrote:
>>
>> > On Sun, Mar 13, 2022, at 3:14 PM, Wojciech Lisik wrote:
>> > > Hello all,
>> > >
>> > > am writing here because this topic
>> > > <https://externals.io/message/117187> has been locked.
>> > >
>> > > I condemn with whole my heart what Russia is currently doing - no
>> > > questions asdked.
>> > >
>> > > But I also think that - in light of current multinational sanctions
>> > > against Russia -
>> > >
>> > >  * all core-team devewlopers of PHP that are of Russia nationality
>> > > should be banned,
>> > >  * their contributions should be removed,
>> > >
>> > > from whole php org on GitHub.
>> > >
>> > > I fully understand that removing contributions of such users like
>> > > *nikic *will break php as a script, but I think that this is the only
>> > > viablle way to protest against what Russia is doing; to show that
>> > > Russian people are welcomed no more anywhere.
>> > >
>> > > Pozdrawiam,
>> > > Wojciech Lisik
>> > >
>> > > Wysłano z bezpiecznej poczty e-mail ProtonMail <
>> https://protonmail.com/>.
>> >
>> > > Attachments:
>> > > * signature.asc
>> >
>> > This is beyond absurd to the point that I have to assume you're
>> trolling,
>> > because the alternative is that you are both intensely racist and
>> intensely
>> > stupid.  Or perhaps all three.
>> >
>> > Normally I would advocate for a gentler touch when someone says
>> something
>> > wrong, but this is so far beyond rational that it doesn't deserve a
>> gentle
>> > response.
>> >
>> > --Larry Garfield
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: https://www.php.net/unsub.php
>>
>>
>> 100% agree with Larry.  Banning people from PHP based solely on their
>> ethnicity is easily the stupidest, most blatantly racist idea I have ever
>> seen proposed here.
>>
>> Absolutely shameful.
>>
>>
>> >
>
>
> I took this as a satirical take on how many other sectors are reacting to
> Russian invasion, not an actual position being advocated for.
>
>
>> --
> Chase Peeler
> chasepee...@gmail.com
>

Lol Poe's Law strikes again.

>

Re: [PHP-DEV] Regarding Russia invasion on Ukraine

[Kris Craig]

On Sun, Mar 13, 2022, 1:36 PM Larry Garfield  wrote:

> On Sun, Mar 13, 2022, at 3:14 PM, Wojciech Lisik wrote:
> > Hello all,
> >
> > am writing here because this topic
> >  has been locked.
> >
> > I condemn with whole my heart what Russia is currently doing - no
> > questions asdked.
> >
> > But I also think that - in light of current multinational sanctions
> > against Russia -
> >
> >  * all core-team devewlopers of PHP that are of Russia nationality
> > should be banned,
> >  * their contributions should be removed,
> >
> > from whole php org on GitHub.
> >
> > I fully understand that removing contributions of such users like
> > *nikic *will break php as a script, but I think that this is the only
> > viablle way to protest against what Russia is doing; to show that
> > Russian people are welcomed no more anywhere.
> >
> > Pozdrawiam,
> > Wojciech Lisik
> >
> > Wysłano z bezpiecznej poczty e-mail ProtonMail .
>
> > Attachments:
> > * signature.asc
>
> This is beyond absurd to the point that I have to assume you're trolling,
> because the alternative is that you are both intensely racist and intensely
> stupid.  Or perhaps all three.
>
> Normally I would advocate for a gentler touch when someone says something
> wrong, but this is so far beyond rational that it doesn't deserve a gentle
> response.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php


100% agree with Larry.  Banning people from PHP based solely on their
ethnicity is easily the stupidest, most blatantly racist idea I have ever
seen proposed here.

Absolutely shameful.


>

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Sun, Mar 6, 2022, 3:14 PM Chase Peeler  wrote:

>
>
> On Sun, Mar 6, 2022 at 5:32 PM Kris Craig  wrote:
>
>>
>>
>> On Sun, Mar 6, 2022, 12:53 PM Chase Peeler  wrote:
>>
>>>
>>>
>>> On Sun, Mar 6, 2022 at 3:40 PM Kris Craig  wrote:
>>>
>>>>
>>>>
>>>> On Sun, Mar 6, 2022, 12:36 PM Chase Peeler 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Mar 6, 2022 at 3:23 PM Kris Craig 
>>>>> wrote:
>>>>>
>>>>>> On Sun, Mar 6, 2022, 10:17 AM Victor Bolshov 
>>>>>> wrote:
>>>>>>
>>>>>> > On Sat, Mar 5, 2022 at 14:26, Kris Craig 
>>>>>> wrote:
>>>>>> >
>>>>>> > Specifically, I would direct this question to Pierre and Viktor: Do
>>>>>> you
>>>>>> > believe that "Arrest Dictator Putin" is appropriate for the PHP
>>>>>> homepage?
>>>>>> >
>>>>>> >
>>>>>> > As a Russian who fled his country because of arising concerns over
>>>>>> Mr.
>>>>>> > Putin's regime, I find any words against him, appropriate. I'm a
>>>>>> pacifist
>>>>>> > but I probably would try to kill him if I was given a chance.
>>>>>> >
>>>>>> > Speaking about how appropriate "Arrest Putin" would be *on the PHP
>>>>>> home
>>>>>> > page*, I'd say no, because I see how many different people have
>>>>>> gathered
>>>>>> > here. We see that even Ukranian flag on PHP homepage is going to
>>>>>> cause
>>>>>> > tensions (what about Iraq & Viet Nam?).
>>>>>> >
>>>>>> > Starting this discussion, I had in mind the "sanity again madness"
>>>>>> > mentality. I even feel sorry now for how this thread brings so many
>>>>>> > disagreements and sol little compromise, so many emotions and so
>>>>>> little
>>>>>> > reason. I still think though that in times like this, stating
>>>>>> something
>>>>>> > like "PHP is against war" is very timely, and it is something we
>>>>>> can agree
>>>>>> > to, without destroying any connections within community.
>>>>>> >
>>>>>>
>>>>>> +1 for a banner that says "PHP is against war".  I would have
>>>>>> absolutely no
>>>>>> objection to that one.
>>>>>>
>>>>> As I’ve said before, I would have a problem with this. War is terrible
>>>>> and should be avoided at all costs. However, there are times it is
>>>>> justified.
>>>>> --
>>>>> Chase Peeler
>>>>> chasepee...@gmail.com
>>>>>
>>>>
>>>> In that case, I think we should scrap this idea altogether.  I mean, if
>>>> we can't even agree that war (i.e. institutionalized mass murder) is a bad
>>>> thing, then there's no statement we could make on this that wouldn't divide
>>>> our community.
>>>>
>>>> I agree we should scrap this for the many reasons people have given
>>> earlier. However, you are misquoting me. I said war was a terrible thing.
>>> Sometimes, though, the alternative is worse. I point you to WW2. How many
>>> more would have died in the holocaust if the allies had not gone to war
>>> against the axis powers?
>>> --
>>> Chase Peeler
>>> chasepee...@gmail.com
>>>
>>
>> From a philosophical perspective, it could be argued that the war was
>> already underway.  And since Hitler started that war to conquer, I would
>> argue that WWII, like every other war, was unnecessary.
>>
>
>
> If no one had fought back, would it have really been a war?
>
>>
>> That's not to say it wasn't necessary for the allies to get involved.
>> But we didn't start that war, and it most certainly was not necessary for
>> Germany to invade Poland.
>>
>
> Exactly my point. We can say we are against war as much as we want, but
> there are evil people in this world that will still prey on others. When
> that happens, “good men” are sometimes forced to fight back.
>
>
>> Fighting a war to end a war is one thing.  Starting a war, on the other
>>
>
> Yep. So you’ve already made caveats to your absolute statement, which was
> my point.
>
>>
>> --
> Chase Peeler
> chasepee...@gmail.com
>

No we're just going by different standards.  When I say war is unnecessary,
I'm not talking about fighting an existing war.  I'm talking about starting
a war.

And it doesn't have to be a formal declaration, either.  The British
effectively waged war against my people before we finally started fighting
back.

Wars begin when some asshole with a lot of power decides he wants to use
that power to take what doesn't belong to him.  War is nothing more than
people murdering each other and destroying humanity's accomplishments.

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Sun, Mar 6, 2022, 3:09 PM  Good Guy   wrote:

> On 06/03/2022 22:32, Kris Craig wrote:
> >  From a philosophical perspective, it could be argued that the war was
> > already underway.  And since Hitler started that war to conquer, I would
> > argue that WWII, like every other war, was unnecessary.
> >
> > That's not to say it wasn't necessary for the allies to get involved.
> But
> > we didn't start that war, and it most certainly was not necessary for
> > Germany to invade Poland.
> >
> > Fighting a war to end a war is one thing.  Starting a war, on the other
> > hand
> >
> Why are you still going on about this.


I'm not.  If you read the thread, you'll see that I was just responding to
a point someone else made.

This is a PHP forum and there is
> no room for history or philosophy lessons here. Just cut it out and move
> on.
>
>
> --
> "Now this is not the end. It is not even the beginning of the end. But
> it is, perhaps, the end of the beginning"
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php




>

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Sun, Mar 6, 2022, 12:53 PM Chase Peeler  wrote:

>
>
> On Sun, Mar 6, 2022 at 3:40 PM Kris Craig  wrote:
>
>>
>>
>> On Sun, Mar 6, 2022, 12:36 PM Chase Peeler  wrote:
>>
>>>
>>>
>>> On Sun, Mar 6, 2022 at 3:23 PM Kris Craig  wrote:
>>>
>>>> On Sun, Mar 6, 2022, 10:17 AM Victor Bolshov 
>>>> wrote:
>>>>
>>>> > On Sat, Mar 5, 2022 at 14:26, Kris Craig 
>>>> wrote:
>>>> >
>>>> > Specifically, I would direct this question to Pierre and Viktor: Do
>>>> you
>>>> > believe that "Arrest Dictator Putin" is appropriate for the PHP
>>>> homepage?
>>>> >
>>>> >
>>>> > As a Russian who fled his country because of arising concerns over Mr.
>>>> > Putin's regime, I find any words against him, appropriate. I'm a
>>>> pacifist
>>>> > but I probably would try to kill him if I was given a chance.
>>>> >
>>>> > Speaking about how appropriate "Arrest Putin" would be *on the PHP
>>>> home
>>>> > page*, I'd say no, because I see how many different people have
>>>> gathered
>>>> > here. We see that even Ukranian flag on PHP homepage is going to cause
>>>> > tensions (what about Iraq & Viet Nam?).
>>>> >
>>>> > Starting this discussion, I had in mind the "sanity again madness"
>>>> > mentality. I even feel sorry now for how this thread brings so many
>>>> > disagreements and sol little compromise, so many emotions and so
>>>> little
>>>> > reason. I still think though that in times like this, stating
>>>> something
>>>> > like "PHP is against war" is very timely, and it is something we can
>>>> agree
>>>> > to, without destroying any connections within community.
>>>> >
>>>>
>>>> +1 for a banner that says "PHP is against war".  I would have
>>>> absolutely no
>>>> objection to that one.
>>>>
>>> As I’ve said before, I would have a problem with this. War is terrible
>>> and should be avoided at all costs. However, there are times it is
>>> justified.
>>> --
>>> Chase Peeler
>>> chasepee...@gmail.com
>>>
>>
>> In that case, I think we should scrap this idea altogether.  I mean, if
>> we can't even agree that war (i.e. institutionalized mass murder) is a bad
>> thing, then there's no statement we could make on this that wouldn't divide
>> our community.
>>
>> I agree we should scrap this for the many reasons people have given
> earlier. However, you are misquoting me. I said war was a terrible thing.
> Sometimes, though, the alternative is worse. I point you to WW2. How many
> more would have died in the holocaust if the allies had not gone to war
> against the axis powers?
> --
> Chase Peeler
> chasepee...@gmail.com
>

>From a philosophical perspective, it could be argued that the war was
already underway.  And since Hitler started that war to conquer, I would
argue that WWII, like every other war, was unnecessary.

That's not to say it wasn't necessary for the allies to get involved.  But
we didn't start that war, and it most certainly was not necessary for
Germany to invade Poland.

Fighting a war to end a war is one thing.  Starting a war, on the other
hand

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Sun, Mar 6, 2022, 12:36 PM Chase Peeler  wrote:

>
>
> On Sun, Mar 6, 2022 at 3:23 PM Kris Craig  wrote:
>
>> On Sun, Mar 6, 2022, 10:17 AM Victor Bolshov 
>> wrote:
>>
>> > On Sat, Mar 5, 2022 at 14:26, Kris Craig  wrote:
>> >
>> > Specifically, I would direct this question to Pierre and Viktor: Do you
>> > believe that "Arrest Dictator Putin" is appropriate for the PHP
>> homepage?
>> >
>> >
>> > As a Russian who fled his country because of arising concerns over Mr.
>> > Putin's regime, I find any words against him, appropriate. I'm a
>> pacifist
>> > but I probably would try to kill him if I was given a chance.
>> >
>> > Speaking about how appropriate "Arrest Putin" would be *on the PHP home
>> > page*, I'd say no, because I see how many different people have gathered
>> > here. We see that even Ukranian flag on PHP homepage is going to cause
>> > tensions (what about Iraq & Viet Nam?).
>> >
>> > Starting this discussion, I had in mind the "sanity again madness"
>> > mentality. I even feel sorry now for how this thread brings so many
>> > disagreements and sol little compromise, so many emotions and so little
>> > reason. I still think though that in times like this, stating something
>> > like "PHP is against war" is very timely, and it is something we can
>> agree
>> > to, without destroying any connections within community.
>> >
>>
>> +1 for a banner that says "PHP is against war".  I would have absolutely
>> no
>> objection to that one.
>>
> As I’ve said before, I would have a problem with this. War is terrible and
> should be avoided at all costs. However, there are times it is justified.
> --
> Chase Peeler
> chasepee...@gmail.com
>

In that case, I think we should scrap this idea altogether.  I mean, if we
can't even agree that war (i.e. institutionalized mass murder) is a bad
thing, then there's no statement we could make on this that wouldn't divide
our community.

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Sun, Mar 6, 2022, 10:17 AM Victor Bolshov  wrote:

> On Sat, Mar 5, 2022 at 14:26, Kris Craig  wrote:
>
> Specifically, I would direct this question to Pierre and Viktor: Do you
> believe that "Arrest Dictator Putin" is appropriate for the PHP homepage?
>
>
> As a Russian who fled his country because of arising concerns over Mr.
> Putin's regime, I find any words against him, appropriate. I'm a pacifist
> but I probably would try to kill him if I was given a chance.
>
> Speaking about how appropriate "Arrest Putin" would be *on the PHP home
> page*, I'd say no, because I see how many different people have gathered
> here. We see that even Ukranian flag on PHP homepage is going to cause
> tensions (what about Iraq & Viet Nam?).
>
> Starting this discussion, I had in mind the "sanity again madness"
> mentality. I even feel sorry now for how this thread brings so many
> disagreements and sol little compromise, so many emotions and so little
> reason. I still think though that in times like this, stating something
> like "PHP is against war" is very timely, and it is something we can agree
> to, without destroying any connections within community.
>

+1 for a banner that says "PHP is against war".  I would have absolutely no
objection to that one.

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Sat, Mar 5, 2022 at 7:05 AM  Good Guy   wrote:

> On 05/03/2022 11:45, Sergey Panteleev wrote:
> >
> > Several members have asked not to have a debate on this mailing list,
> > let's respect their opinions too.
> >
> >
> >
>
> It's not debating. The original post was simply asking to show true
> colors of Ukraine's flag in these posts but HTML is not allowed here. I
> have created a simple HTML code that show something like this:
>
> Arrest Dictator Putin 
>
>
> --
>
> With over 1.7 billion devices now running Windows 10/11, customer
> satisfaction is higher than any previous version of windows.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
> Ffs this is exactly what I'm talking about!  Are we talking about putting
out a statement of solidarity with the victims of war or are we talking
about putting out a political statement demanding the arrest of a world
leader?  *THE TWO ARE NOT ONE AND THE SAME!! *

So before we continue any further, we need to figure out EXACTLY what's
being proposed here because everybody seems to have a wildly different
interpretation of that.  Specifically, I would direct this question to
Pierre and Viktor:  Do you believe that "Arrest Dictator Putin" is
appropriate for the PHP homepage?  Is that what you meant when you said you
support a statement of solidarity?  I'm asking because it seems like there
are two very distinct camps among those who want to put out a statement:
One camp wants to express solidarity while the other seems more concerned
with personally condemning Vladimir Putin and demanding his arrest.

I'd feel a lot better about this if people would clarify which of these
camps they fall into.  It would be one thing if we had previously put up
something like "Arrest Dictator Bush" back in the day, but we didn't.  And
I'm not comfortable with the implied statement we'd be making that one
illegal invasion that displaces and murders innocent civilians is ok but
the other is not.

Could somebody please suggest a less politically divisive banner?  It
should focus on standing with the victims of war, not demanding arrests and
prosecutions.  That's not what the PHP homepage is for.

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Sat, Mar 5, 2022 at 2:29 AM Maxime Veber  wrote:

> Guys, there's no place for debate here.
>
> You may not like how Marco is talking to you but he's deeply right.
>
> I'll be asking only one thing: what help do you need for a warning to
> appear on the PHP website.
> - Pull request with a flag?
> - Content for an article saying the PHP community stands with Ukraine and
> demands the end of any fight in Ukraine?
>
> Debate has no place here, let's start concrete action please.
>
> With hope and sadness,
> Maxime
>
> *–*
> Maxime
>
>
> Le sam. 5 mars 2022 à 10:58, Marco Pivetta  a écrit :
>
>> On Sat, 5 Mar 2022, 04:31 Kris Craig,  wrote:
>>
>> >
>> >
>> > On Wed, Mar 2, 2022 at 4:51 AM Marco Pivetta 
>> wrote:
>> >
>> >> Hey Christian,
>> >>
>> >> On Wed, Mar 2, 2022 at 1:41 PM  wrote:
>> >>
>> >> > this is exactly the problem. Russia did not just invaded Ukrainia
>> out of
>> >> > nowhere. The story started in 2014 with the illegal coup d'etat
>> against
>> >> > Viktor Yanukovych and its acceptance by the western countries. Or
>> even
>> >> > earlier, with the eastern extension of the EU and the Nato, to get
>> >> Ukriane
>> >> > on their side, stoping the political neutrality of Ukraine between
>> >> Russia
>> >> > and the western.
>> >> >
>> >> > As you see, it is not as simple. Should we start a discussion now? I
>> do
>> >> > not think so. It would not help anybody. Wars or conflicts are never
>> >> > simple. Usually there's a long story.
>> >> > Taking ones side in political conflicts will separate the community
>> for
>> >> > sure.
>> >> >
>> >> > Please do not start that.
>> >> >
>> >> > You and anybody else can show their political position on twitter,
>> >> > facebook or elsewhere. We do not need to do that on php.net.
>> >> >
>> >>
>> >> Please GTFO: we don't need more of Putin's propaganda over here, as
>> >> they're
>> >> busy enough with butchering civilians over there.
>> >>
>> >> Greets,
>> >>
>> >> Marco Pivetta
>> >>
>> >> http://twitter.com/Ocramius
>> >>
>> >> http://ocramius.github.io/
>> >
>> >
>> > I find this deeply, deeply disturbing.
>> >
>>
>> Good: time for some self introspection then.
>>
>> As for the rest of the thread, I am deeply ashamed of the state of
>> php-internals.
>>
>> https://youtube.com/watch?v=Gfsiw2pf_Y0=1h44m48s
>>
>> I will take (continue taking) action elsewhere: the fact that some of you
>> are "disturbed" by my message, means that it came through as intended.
>>
>> >
>>
>
"Debate has no place here"?!  Since when?

Seriously, this is just getting downright creepy.  I think just about
everybody here agrees that Putin is a war criminal and an all-around ass
who deserves to be brought to justice for his many crimes, including those
against Ukraine.  However, there is legitimate disagreement over the scope
of our response.

This is a perfect example of what I've been talking about:  You have some
people advocating a general message of support for the victims of the
conflict, but then there are others like you who advocate a more political
response like making demands and condemnations.  Given that PHP has never
done this in the past, despite many occasions that easily compare to what's
happening now, doing so now I fear would send a mixed message.  Broaden the
statement to condemn past invasions like Iraq, Afghanistan, Libya, and
Vietnam, then I'd be ok with it, though I still question the
appropriateness of including any political messages not directly pertaining
to internet freedom on the PHP website.  It just makes me nervous because
it sets a precedent that could be very easily abused in the future and
all-but certainly will be.

Looks to me like there's plenty of room for debate here.  To be clear, I
would wholeheartedly, vehemently object to ANY decision being made about
this one way or the other without our usual process of open and thorough
debate.  Declaring that there will be no debate is basically the equivalent
of saying, "I've decided we're doing things my way and you can all suck
it."  Seriously, it felt really, really disrespectful and exclusionary.

I'm always weary of anyone who demands that a group decision be made
without discussion or debate.  Not only does that fly in the face of this
community's longstanding tradition, but it also completely ignores the
glaring irony that "Debate has no place here" is a phrase you'd expect to
hear uttered in Russia, not on this listserv.

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Fri, Mar 4, 2022 at 10:16 PM Pierre Joye  wrote:

>
>
> On Sat, Mar 5, 2022, 10:31 AM Kris Craig  wrote:
>
>> On Wed, Mar 2, 2022 at 4:51 AM Marco Pivetta  wrote:
>>
>>
>> But that doesn't mean we should be using the PHP website to start taking
>> sides in military conflicts.
>>
>
> There is no side to take but the population in Ukraine, friends, family,
> colleagues as well as in Russians, the victims of a dictatorship' lies.
>
> I don't see any issue to show our support for them, quite the opposite, I
> do see an issue not to show it. A link to red cross and other ong
> supporting refugees and civilians is not political, it is being a human.
>
> It does not mean we take a political side. As much as there is not much to
> discuss about that, but the deconstruction,  point by point, of every
> single claim to justify this invasion, but php.net is not the place for
> that.
>
> best,
>

I think we need to draw a really important distinction here then.  On the
one hand, you describe showing support for the Ukrainian people, civilians,
refugees, and relief organizations.  I agree with you on this, as I imagine
most would.  Helping the innocent shouldn't be political.  But on the other
hand, you have other people here advocating that we condemn the invasion,
itself, as well as Russia and Vladimir Putin.  While I agree they're fully
deserving of condemnation, this part is inherently political, and I
question the appropriateness of including such a blatantly political
message on our website.  I don't oppose the message, itself, but I do fear
the precedent it would set, especially in the absence of previous
condemnations by us of illegal invasions in the past.

If all we're talking about is a message of solidarity with the victims of
war, I'm all for it.  I'd also be for a general condemnation of all illegal
wars/invasions, including this one.  At least then we're being consistent
IMO.

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Kris Craig]

On Wed, Mar 2, 2022 at 4:51 AM Marco Pivetta  wrote:

> Hey Christian,
>
> On Wed, Mar 2, 2022 at 1:41 PM  wrote:
>
> > this is exactly the problem. Russia did not just invaded Ukrainia out of
> > nowhere. The story started in 2014 with the illegal coup d'etat against
> > Viktor Yanukovych and its acceptance by the western countries. Or even
> > earlier, with the eastern extension of the EU and the Nato, to get
> Ukriane
> > on their side, stoping the political neutrality of Ukraine between Russia
> > and the western.
> >
> > As you see, it is not as simple. Should we start a discussion now? I do
> > not think so. It would not help anybody. Wars or conflicts are never
> > simple. Usually there's a long story.
> > Taking ones side in political conflicts will separate the community for
> > sure.
> >
> > Please do not start that.
> >
> > You and anybody else can show their political position on twitter,
> > facebook or elsewhere. We do not need to do that on php.net.
> >
>
> Please GTFO: we don't need more of Putin's propaganda over here, as they're
> busy enough with butchering civilians over there.
>
> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.io/


I find this deeply, deeply disturbing.  In response to someone making the
argument that using the PHP website to take sides in military conflicts
between nations would risk dividing our community, you told him to "get the
fuck out" and accused him of promoting "Putin's propaganda".  From where
I'm sitting, this looks like a blatant effort on your part to silence any
dissent on this by immediately demonizing critics of this idea as Russian
operatives.  Are you going to accuse me of being a Russian spy now, as well?

To be clear, I don't support Putin's invasion of Ukraine.  In fact, I was
denouncing Putin on social media as a brutal dictator before it was cool,
back when the western news media was still singing his praises.  He's a war
criminal piece of garbage and the world will be much better off when he's
finally gone.

But that doesn't mean we should be using the PHP website to start taking
sides in military conflicts.  I just don't like the precedent we'd be
setting, especially since, as others have already pointed out here, we
never took any such stand against the U.S. invasions of Afghanistan, Iraq,
or Libya.  So if we were to start doing that now, it would look pretty damn
hypocritical of us.  Plus I don't want us to start having to deal with
batshit conspiracy theories about how PHP is secretly controlled by the
U.S. government.  Besides, it should be noted that PHP is not a political
organization.

If anybody's open to a compromise proposal, how about a general statement
of support for the peoples of Ukraine and any other nation currently
besieged by foreign invaders.  That I think would be far less divisive, as
evidenced by some of the messages we're seeing in this thread.  Accusing
every random dissenter of being an agent of Vladimir Putin just reeks of
logical fallacies, not to mention paranoia.  Reverting back to a
McCarthyist mindset will not help the people of Ukraine.

So can we please try to tone this down a bit?  I read through this entire
thread (painful though it was in places) and was not able to find anything
that any reasonable observer would regard as "Putin propaganda".  Nobody
here is a Russian secret agent trying to mindfuck us.  What I see is a
group of people who believe PHP needs to take a stand on this issue and
another group of people who believe PHP has no business getting involved.
Both are valid arguments worthy of debate, which means there's absolutely
NO NEED to question people's motives or demonize them as being agents of
Putin or the U.S. or whatever else.  Just debate the merits of the issue,
take a vote, and we're good.

Alternatively, I also like Viktor's idea of making a broader statement
against war in general.

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

[Kris Craig]

On Tue, Dec 21, 2021 at 3:21 PM Wade Rossmann  wrote:

> On Sun, Mar 21, 2021 at 9:52 AM Larry Garfield 
> wrote:
>
> > On Sun, Mar 21, 2021, at 9:18 AM, Rowan Tommins wrote:
> > > Hi all,
> > >
> > > The functions utf8_encode and utf8_decode are historical oddities,
> which
> > > almost certainly would not be accepted if proposed today:
> > >
> > > * Their names do not describe their functionality, which is to convert
> > > to/from one specific single-byte encoding. This leads to a common
> > > confusion that they can be used to "fix" UTF-8 encoding problems, which
> > > they generally make worse.
> > > * That single-byte encoding is ISO 8859-1, not its common cousins
> > > Windows-1252 or ISO 88159-15. This means, for instance, that they do
> not
> > > handle the Euro sign: utf8_decode('€') returns '?' (i.e. unmappable)
> > > not "\x80" (Windows-1252) or "\xA4" (8859-15)
> > >
> > > On the other hand, they are commonly used, both correctly and
> > > incorrectly, so removing them is not easy.
> > >
> > > A previous proposal to remove them [1] resulted in Andrea making two
> > > significant improvements: moving them from ext/xml to ext/standard [2]
> > > and rewriting the documentation to explain them properly [3]. My
> genuine
> > > thanks for that.
> > >
> > > However, it hasn't stopped people misunderstanding them, and quite
> > > reasonably: you shouldn't need to look up every function you use in the
> > > manual, to make sure it actually does what its name suggests.
> > >
> > >
> > > I can see three ways forward:
> > >
> > > A) Raise a deprecation notice in 8.1, and remove in 9.0. Do not provide
> > > a specific replacement, but recommend people look at iconv() or
> > > mb_convert_encoding(). There is precedent for this, such as
> > > convert_cyr_string(), but it may frustrate those who are using the
> > > functions correctly.
> > >
> > > B) Introduce new names, such as utf8_to_iso_8859_1 and
> > > iso_8859_1_to_utf8; immediately make those the primary names in the
> > > manual, with utf8_encode / utf8_decode as aliases. Raise deprecation
> > > notices for the old names, either immediately or in some future
> release.
> > > This gives a smoother upgrade path, but commits us to having these
> > > functions as outliers in our standard library.
> > >
> > > C) Leave them alone forever. Treat it as the user's fault if they mess
> > > things up by misunderstanding them.
> > >
> > >
> > > I am happy to put together an RFC for either A or B, if it has a chance
> > > of reaching consensus. I would really like to avoid option C.
> > >
> > >
> > > [1] https://externals.io/message/95166
> > > [2] https://github.com/php/php-src/pull/2160
> > > [3]
> > >
> >
> https://github.com/php/doc-en/commit/838941f6cce51f3beda16012eb497b26295a8238
> > >
> > > Regards,
> >
> > I lost several days of my life to exactly this problem, many years ago.
> I
> > am still triggered by it.
> >
> > I am mostly OK with option A, but with a big caveat:
> >
> > The root problem here is "You keep using that function.  I do not think
> it
> > means what you think it means."
> >
> > As Rowan notes, what people actually *want* most of the time is "I got
> > this string from a user and have NFI what it's encoding is, but my system
> > needs UTF-8, so gimmie this string in UTF-8."  And they use
> utf8_encode(),
> > which then fails *sometimes* in exciting and mysterious ways, because
> > that's not what it is.
> >
> > Removing utf8_encode() may keep people from misusing it, but that doesn't
> > mean the problem space they were trying to solve goes away.  If anything,
> > people who still don't realize that it's the wrong solution will get
> angry
> > that we're taking away a "useful" tool and replacing it with "meh, go
> look
> > at library X," which is admittedly a pretty rude answer.
> >
> > If we're removing a bad answer to the problem, we should also replace it
> > with a good answer.
> >
> > Someone will, I'm sure, pop in at this point and declare "if you don't
> > know the character encoding you're receiving, then you're doing it wrong
> > and are already lost and we can't help you."  While that may be
> technically
> > correct, it's also an entirely useless answer because strings received
> over
> > HTTP very frequently do not tell you what their encoding is, or they lie
> > about what their encoding is.  (The header may say it's ISO8859, or UTF8,
> > or whatever, but someone copy-pasted from MS Word into a text box and now
> > it's Windows-1252 within a wrapper that says ISO8859 but is mostly UTF8
> > except for the Windows-1252 part.  Like, that's literally the problem I
> > lost several days to.)  "Your own fault" is not even an accurate answer
> at
> > that point.
> >
> > So if we're going to take away people's broken hammer, we need to be very
> > clear about what hammer to use instead.
> >
> > The initial answer is probably "here's how to use a series of mb_string
> > functions together to produce a reasonably good
> > 

Re: [PHP-DEV] Replies on lists.php.net

[Kris Craig]

On Tue, Feb 23, 2021 at 7:30 AM Chase Peeler  wrote:

> On Tue, Feb 23, 2021 at 10:27 AM Ben Ramsey  wrote:
>
> > > On Feb 23, 2021, at 09:21, Larry Garfield 
> > wrote:
> > >
> > > On Mon, Feb 22, 2021, at 4:26 AM, Christian Schneider wrote:
> > >> Am 15.02.2021 um 13:20 schrieb Pierre :
> > >>> I noticed I receive almost all your replies to the list along with a
> > duplicated copy addressed to me or other conversation participants, I
> think
> > you always click "reply to all" instead of "reply to list" in your mail
> > client.
> > >>
> > >> I think if our intention is that the default reply should go to the
> > >> list then the mailing list should be configured to include a
> > >>  Reply-To: "php internals" 
> > >> header which it currently does not, right?
> > >>
> > >> This would make it harder to send a reply directly to the author (in
> > >> some clients you have to click reply and then copy the address) but it
> > >> would not depend on the reply-to-list feature not all mail clients
> have.
> > >>
> > >> - Chris
> > >
> > > +1 Endorse
> >
> >
> > Also +1
> >
> > I had no idea that it was double-sending messages to folks when I did
> > reply-all. My mail client must filter the messages appropriately so that
> I
> > only see one message, and I don’t have a reply-to-list option.
> >
> > Cheers,
> > Ben
> >
> >
> >
> The gmail web client has the sender as the reply-to, and the list in the cc
> (at least in this case). On the receiving side, I don't get duplicates, so
> I assume gmail is smart about filtering those out.
>
> --
> Chase Peeler
> chasepee...@gmail.com


I also use Gmail and haven't encountered the duplicate message issue in
quite a long time.

+1 on the reply-to idea.  That would represent a really easy fix, I think.

--Kris

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

[Kris Craig]

>
> > and as explained in the past: if *you guy* ever again contact my
> > employer asking for the law department beause you think some bugreport
> > written late at night with a obfuscated email was from me i will *find
> > and fuck* you


Wait did somebody actually contact this troll's employer?!  Seems like an
unnecessary escalation to me.  I think this may be a perfect example of the
timeless wisdom of the phrase, "Do not feed the trolls."

Might be better to just block all of his known emails from the list.  If he
gets around this by emailing people individually, I agree that publishing
it here with the email address included would be useful, as it would enable
everyone to individually block their emails then.

--Kris


>
>
>

Re: [PHP-DEV] Adding explicit intent for SWITCH/CASE fall through?

[Kris Craig]

On Sat, Oct 19, 2019 at 12:06 AM A.L.E.C  wrote:

> On 10/18/19 8:57 PM, Mike Schinkel wrote:
>
> Imo, this would make more sense if fallthrough did something more, e.g.
> allowing
>
> case X:
> if (something) {
> fallthrough;
> }
> something-else;
> break;
> case Y: 
>
>
+1

If we're going to do this, let's take the opportunity to make it even more
useful.  I love the idea of being able to explicitly define fallthrough
points in a case.

I agree that "continue" is the logically ideal solution, but the BC
breakage negates that.  So I'd have to go with "next", as it's both concise
and descriptive.

--Kris

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

[Kris Craig]

On Sun, Oct 6, 2019 at 12:36 PM Zeev Suraski  wrote:

> On Fri, 4 Oct 2019 at 17:45 Mark Randall  wrote:
>
> > Hi Internals,
> >
> > I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> > discussion.
> >
>
>
> Mark, all,
>
> I’m not sure what planetary alignment or moon phase triggered this recent
> compatibility-breaking onslaught, but it can’t go on like this.  The fact
> we have to repeatedly work to *keep things working* is an unacceptable
> waste of too many people’s time.
>
> When you joined as contributors, you made an informed decision to join an
> existing project that isn’t starting from scratch.  You’re ~20 years too
> late for these kinds of discussions.  This ship has sailed so long ago it’s
> in the outskirts of the Milky Way by now.  Contributions are welcome, but
> an endless stream of deprecation proposals that bring absolutely no new
> evidence to the table are not contributions.  This RFC, indeed, falls
> squarely within that category.
>
> All, please focus on adding value to PHP instead of finding ways to break
> perfectly working code, even if it’s code you don’t particularly like.
>
> Zeev
>

We seem to be experiencing something of a philosophical clash with regard
to deprecation.  Perhaps we should attempt to establish some general
guidelines for deprecation as a group?

--Kris

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] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Kris Craig]

On Fri, Aug 9, 2019 at 6:25 AM Robert Korulczyk  wrote:

> > Disabling short tags now is done with "an explicit directive" (there has
> to be a specific ini file with a specific setting 'short_open_tag = 0').
> > Isn't this the same "situation when you create a separate file with an
> explicit directive"?
>
> No, it's not. `php.ini` is outside of project responsibility - as a
> developer you don't really configure this in any way, your application does
> not
> have any explicit directive to disable/enable short open tags. You just
> accidentally using feature that could lead to code leak.
> In your example with `engine` directive you explicitly disable PHP engine
> by creating dedicated file for that purpose - there is no way do to this by
> accident and then does not notice it.
>
>
> > If a coder (or IDE) has written ' unless tested the effect (a part of code not being parsed/executed) will be
> > exactly the same if the feature suddenly disappeared (unless the
> additional checks in the 'v2 RFC' which on the other hand would make the
> engine a
> > tiny bit slower but probably have to be implemented to avoid such
> accidents).
>
> At least the this behavior will be consistent - you will not have cases
> when code works fine on one environment and leak on another.
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
So far, the RFC only has 55% support, which means it's not going to pass
this time, anyway, unless there's a vote shift in the next 8 days.

Re: [PHP-DEV] Bringing Peace to the Galaxy

[Kris Craig]

On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov  wrote:

> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski  wrote:
>
> >
> >
> > On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov 
> wrote:
> >
> >> This is basically what I have been advocating for a while now already,
> >> somewhat hidden between all the other noise of the "namespace-scoped
> >> declares" thread. The model I would like to follow are Rust editions (
> >> https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP
> >> right now, the way to do this technically would be based on a
> >> declare(edition=2020) in every file. I was hoping to make this a
> >> per-package declaration instead, but haven't found the perfect way to do
> >> this right now.
> >>
> >
> > I think it's similar, but not quite the same, at least as far as what I
> > understood from what you were saying on that thread (I just reread it).
> > First, I think it's important we don't only focus on what we're going to
> > change - but also on what we're going to keep.  The motivation should not
> > be slow eventual migration from one codebase to another.  We would have
> > two, long-term supported codebases - a lot closer to C and C++ than to
> > different editions of a single language.  The distance between them would
> > be quite substantial from the get-go - and will likely grow farther as
> time
> > goes by, similarly to the situation with C and C++.
> >
>
> I think this part is unrealistic from a simple manpower perspective. We
> have something like ~2 full time developers working on PHP. Even if you can
> rally some additional interest around this idea, I don't think we have the
> resources to create a *substantially* different language in any reasonable
> amount of time. Doing feature additions and changes to PHP is Hard. Even
> simple changes require a fair bit of design and engineering effort to
> integrate with the large complexity of the existing language. This would
> not change for a hypothetical P++, because we still need to interoperate
> with PHP.
>
> Even if I agreed with the idea (which I'm pretty skeptical about in this
> particular form), I really don't think we have the resources to do
> something like this.
>
> Nikita
>
>
I think it should also be pointed out that there's nothing stopping anyone
from forking PHP into a new project as Zeev described and maintain feature
parity.  As I understand, the reason something like this hasn't happened
already is because it would involve a ton of work and nobody wants to deal
with it.  But if you or anyone else does manage to put a team together and
make something like this happen as a separate project, I'd certainly have
no objection.

--Kris

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

[Kris Craig]

On Mon, Feb 4, 2019, 7:18 PM Andrey Andreev  Hi,
>
> I was avoiding this, but since the discussion has already turned into
> all about who gets to vote, I might as well ...
>
> On Tue, Feb 5, 2019 at 1:46 AM Zeev Suraski  wrote:
> > the barrier to obtaining a vote is ridiculously low.
>
> You keep saying that, but it hasn't been explained how it is so.
>
> Is it the PEAR-only contributors that you want to eliminate? The doc &
> translations teams? Old-timers who are no longer interested in the
> project? Is there a common occurrence of existing leaders granting VCS
> accounts to friends for no reason?
> I mean, if you want to reduce thousands to sub-200, you might as well
> put down all your cards.
>
> Aside from a couple of past cases where "ghost" voters were mobilized
> for a huge, controversial RFCs, I haven't seen a problem with the
> current voting pool members (and thus see little reason to attempt to
> change it), but I also think it's sensible that e.g. translating a
> couple of lines in the docs isn't enough. In any case however, the
> criteria and metrics that you've chosen are, to me, quite arbitrary
> and only appear fair while not actually being so, especially the 25
> commit count.
>
> Full disclosure - that last one is what disqualifies me. Although, I
> certainly don't consider myself a "core" developer, so if your
> intention is to limit voting power to only that group I guess it has
> achieved the goal in my case.
> On the other hand, I qualify under all the current status-quo criteria
> - I've contributed some code, features, tests, docs; had a couple of
> RFCs; am a lead framework developer; participate somewhat regularly in
> internals discussions - yet obtaining voting privilege wasn't as easy
> as a "ridiculously low bar" would make you believe.
>
> Anyone who has ever attempted to use such metrics for evaluation would
> tell you that commit count is a horrible one. It makes no difference
> between 25 and 25k lines, quality or significance.
> It doesn't give any weight to participation in discussions either,
> whether its on this list or code reviews, both of which I believe are
> influential and valuable.
> Some squash commits, some don't; I've had my own commits squashed AND
> authored by the person who merged them, meaning my name isn't attached
> to them at all. This is an example of a previously meaningless factor
> all of a sudden becoming a deciding one.
> There are some well-known names that don't make the cut in Appendix A
> and that does raise an eyebrow.
>
> If you want to say that there are people with voting privileges that
> haven't earned them, that's one thing, but (and I'm not assuming bad
> intentions with this) as it stands it looks like you just wanted to
> cut as much as possible and only looked for a metric that wasn't going
> to eliminate the very top contributors, whom you can't afford to lose.
>
> Cheers,
> Andrey.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Stripping any existing contributors of our voting rights is a non-starter
for me, period.  Any changes must not be applied retroactively, as that
would just lead to all kinds of problems and severe animosity/drama.

The eligibility needs to be moved to its own RFC and fixed so that it
doesn't overreach by trying to force out existing voters.  Otherwise you
can count me as a firm "no" on this one.

>
>

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 

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

[Kris Craig]

Now THIS is a sensible proposal!  It resolves the biggest issues in a very
simple and straightforward manner.  And unlike the other RFC, this proposal
does not feel like an exclusionary power grab.

--Kris

On Sat, Feb 2, 2019, 8:24 AM Nikita Popov  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.
>
> The remainder of the workflow & voting RFC is mostly concerned with
> defining stricter rules and more rigid procedures for the RFC process. It
> increases the amount of bureaucracy and overhead involved in the RFC
> process, making the RFC processes even less suitable for smaller changes
> than it already is.
>
> The proposal I would like to present in the following is not my own idea,
> it has been suggested by Anthony Ferrara. Because I found the idea very
> compelling, I'm presenting it to the list now.
>
> ---
>
> Instead of making the RFC process more complex and rigid, we should
> simplify and streamline it. The RFC process is reduced to only two rules:
>
> 1. All primary RFC votes require a 2/3 majority, while secondary votes
> resolving implementation details may use a simple majority. (This is
> already proposed in the voting margins RFC, so discussion about this point
> should be directed into the corresponding RFC thread.)
>
> 2. All RFCs must have a voting period of at least 14 days, announced in a
> separate [VOTE] thread.
>
> ---
>
> That's it. More notable than the rules itself are probably the two main
> omissions:
>
> 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.
>
> The motivation for not having a fixed discussion period (but a longer
> minimum voting period) is that RFCs come in many different forms and sizes.
> Some RFCs are long and complex (such as the recent typed properties RFC)
> 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.
>
> 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
> itself and the activity of the discussion. (It is an unfortunate fact that
> many RFCs receive their first meaningful feedback during the voting
> period.)
>
> 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.
>
> 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.
>
> It should go without saying that if you restart a failed RFC vote without
> making substantial changes to the RFC, the result is unlikely to change in
> your favor, and that continued misbehavior might be seen as spam.
>
> ---
>
> 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.
>
> What do you think?
>
> Regards,
> Nikita
>

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

[Kris Craig]

On Thu, Jan 31, 2019 at 11:57 PM Stanislav Malyshev 
wrote:

> Hi!
>
> I haven't fully read the RFC yet, so I'll come back with more formed
> opinion about it probably, but wanted to comment about a couple of
> points here:
>
> > Reasoning: If somebody is out of the project for 10 years they probably
> > lost track on how the language and needs evolved and just voting since
> > an old friend needed a deciding vote is bad.
>
> I agree, though "out of project" can differ... But I think if the person
> had made no contribution for a decade, then probably he wouldn't be very
> well informed voter. Easier way would be to make the list of such people
> and let them ask on the list that their vote will be kept if they want
> to, with explanation on how they plan to continue contribute (we don't
> have to require actual contribution, just people promising to do so - we
> are all volunteers here anyway). People that have long moved on would
> just ignore that, and people who want to come back will do so.
>
> > For groups like FIG I am uncertain. I think it is a good thing if we
> > push more things out of PHP itself into the userspace (JIT, FFI, ...
> > allow more and more stuff to be done in userspace) and thus
> > coordinating with userspace developers and setting standards and
> > interoperability there is good. However it are the maintainers who
> > (often voluntarily) have to maintain these things and overruling actual
> > maintainers is bad as they lose interest.
>
> Yeah I'm feeling a bit uneasy about the FIG part too. I mean, having
> input from major userspace groups is great. But having input and having
> deciding voice is a different thing. Discussion and vote are different
> processes, both important but with different results. So I wonder if we
> can't find some venue to collect this feedback without having people who
> aren't core developers decide for core developers what should they do.
> This sounds like something that won't be healthy.
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
The more I think about this, the less I like it.  According to the page
linked to from the RFC, there are 51 current FIG members who would gain a
vote.  So this RFC would strip most contributers of their voting rights
(including me), while simultaneously adding 51 new voters, all from the
same external organization (one that has been aggressively gunning for
"official" recognition since its inception).  In other words, this RFC, in
its current form, would have effectively handed control over the entire PHP
project to FIG.  Though I'm sure it was never the intent, TBH, this does
feel like a bit of a slap in the face to past contributors who still have
good ideas to offer now and then and should still have a voice.
Furthermore, it seems strange to me that a provision with such massive and
far-reaching implications would be quietly buried at the bottom of an RFC
filled with otherwise popular, non-controversial ideas.

There are a lot of people like me who, while we may not be active core
contributors, we have contributed in different ways over the years and we
deserve better than to be pushed aside like this.  I dedicated a full year
of my life to this project and made a number of contributions to our test
automation during that time, as well as put a lot of time into testing and
debugging during the 5.3.3 release cycle.  To say that I should be denied a
vote now only serves to discourage me from being active again in the
future.  While I agree that we should tighten-up our standards regarding
who gets to vote, I am increasingly convinced that attempting to apply it
retroactively to existing contributors at all would be a mistake.  It just
looks like a solution in search of a problem, seeing as how most of those
inactive people don't vote anymore, anyway.  Furthermore, having a more
diverse voter base that includes people not directly involved with the
day-to-day core work helps to prevent any changes that would be wildly
unpopular with the community from being rubber-stamped.

I'm sorry but I must repeat my request that this provision be removed and
placed in a separate RFC.  I don't see how there's any way I'd be able to
support this otherwise.  Are you outright refusing to split it up or are
you open to discussing it in light of these concerns that have been raised
by myself and others?

--Kris

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

[Kris Craig]

On Thu, Jan 31, 2019, 7:58 AM Kalle Sommer Nielsen  Hi Zeev
>
> Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
> >
> > 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:
> >
> >
> >
> > https://wiki.php.net/rfc/voting2019
>
> I wholeheartedly disagree with the PHP-FIG special exception to who
> can vote, call me biased but I do not believe it serves any purpose
> and is absurd. People who actively work on PHP, should be the ones to
> be able to have a choice, I think that should be reserved for any
> contributor who puts effort working on PHP.
>
> I do understand that we are the language and our work affects the
> others the most. However making special exceptions for who can vote
> and essentially having a say from an external source in what I in
> theory need to help maintain as a PHP Core Developer is terrible. Why
> not allow WordPress Core Developers to have a say instead, as their
> work has a larger impact on the usage of PHP? (That was obviously a
> bit of sarcasm, the last part). We are not allowed to vote at their
> individual projects features (nor do we need to have a say if we are
> not actively involved in the development of said projects or
> organizations) and I stand very strongly behind that belief.
>
> Besides this, it also creates uncertainty about who elects such, and
> simply should be dropped from the voting RFC as it was already fairly
> unclear from the original one.
>
> The contributors appendix also lists ChangeLog, SVN Migration etc,
> something to keep in mind if this RFC is moved forward to filter the
> list.
>
>
> Do I understand the PHP Packaging Decisions right that it requires to
> vote for a timeline for each version? I remember we have different
> opinions raised regarding the time to a new major version (should we
> have 7.4 vs go to 8.0, same for the 5 to 7 transition back then
> regarding a 5.7). This is the only issue I can think of and should be
> changed to requiring a vote if there is a dispute in regards to what
> the next version should be. As I don't really wanna vote just to vote
> for each of the minor versions of 8 once a year when its the most
> logical reason to go to 8.1 from 8.0, and so on until we reach the
> point where the next major is considerable.
>
>
> I think changes like the requiring a patch for RFCs is a very welcomed
> addition.
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Given how complex and controversial this question of restricting who can
vote is, I propose that it be moved to its own RFC instead of being bundled
with this one.  It would certainly boost likelihood of passage, if nothing
else, as there are a lot of good ideas in this RFC.

--Kris

>
>

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

[Kris Craig]

I think you may be over-reaching a bit on the eligible voters part.  Keep
in mind that all those who would be affected would still be able to vote on
this RFC.  I think it's too restrictive on that part.

Also, why does FIG get special treatment?

--Kris


On Thu, Jan 31, 2019, 5:44 AM Zeev Suraski  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:
>
>
>
> https://wiki.php.net/rfc/voting2019
>
>
>
> Emphasis on ‘attempting’.  I’m sure there are still a lot of holes in it
> that should be plugged before we vote on it, but instead of waiting
> indefinitely – I’d like us to start discussing it.
>
>
>
> Comments and suggestions welcome.
>
>
>
> Zeev
>
>
>
>
>
>

Re: [PHP-DEV] Official Twitter Account

[Kris Craig]

On Thu, Dec 6, 2018 at 10:08 AM Sara Golemon  wrote:

> On Thu, Dec 6, 2018 at 11:09 AM Trevor Suarez  wrote:
>
> > In any case, I feel like its usually the last place where I see
> > announcements made.
>
> I'll take exception to that.  I've been pushing both branches of the last
> several releases, and tweeting about it just after the announcements are
> visible on news.php.net.
> So no, if it's the last place you're seeing it, then you're only visiting
> fortune tellers.
>
>
> > For example, there's no tweet yet about the
> > announcement/availability of the PHP 7.3.0 release.
> >
> > Because I batch them, and the 7.0.33 announcement hasn't gone out yet.
> When that announcement happens, you'll see a tweet.
>
>
> > Its not a huge deal, really, but I follow a lot of PHP community members
> > that have all tweeted about 7.3.0 and I'd like to point people to the
> > official account for official announcements.
> >
>
> Because Europeans have different sleeping hours than Americans.
>
>
> > Maybe, in the future, tweeting from that account can be made a part of
> > coordinating an announcement? Just a thought. :)
> >
> > It is already.
>

Have we ever considered automating these social media posts?  Not just
Twitter, but Reddit, as well.   A bot could be setup to monitor for
announcements and repost them to social media without it having to be done
manually.

--Kris

Re: [PHP-DEV] Re: Consistent indentation for test files

[Kris Craig]

On Sat, Oct 28, 2017 at 5:42 AM, Christoph M. Becker 
wrote:

> On 28.10.2017 at 13:59, Nikita Popov wrote:
>
> > Right now we do not have a consistent standard for the indentation of
> PHPT
> > files. Some people create space-indented files, others create
> tab-indented
> > files. Over time, indentation invariably starts to mix, because
> developers
> > with different indentation settings work on one file.
> >
> > Here are the current statistics for code in .phpt files:
> >
> > total: 15515
> > prefer tabs: 4273 (27.5%)
> > prefer spaces: 6307 (40.7%)
> > draw: 77 (0.5%)
> > no indentation: 4858 (31.3%)
> >
> > There are 1824 (11.8%) files that contain mixed tab and space
> indentation.
> > The indentation was determined based on the first character of a line.
>
> Thanks for bringing this up!
>
> > I would like to propose that we establish a common standard by
> > a) using space indentation for all future tests (as they currently form
> the
> > majority), and
> > b) reindenting existing test files to use space indentation.
>
> +1
>
> I'm rather baffled that  doesn't
> address this issue at all.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Those stats can be a bit misleading, though, as I've observed that many (if
not most) IDEs are configured to automatically convert tab characters to
spaces.  Therefore, it stands to reason that at least some of the "prefer
spaces" category would actually fall under "prefer tabs".  I suspect the
tabs and spaces groups are much closer together, though it's impossible to
say how much since there's no way to control for that variable.  Still, I
would caution people not to read too much into those statistics.

A common standard would be nice, but I fear it might discourage some from
contributing tests.  Also, how would we actually enforce this?  Would we
reject any tests that don't conform to this or fix them, ourselves?  Either
way, it would require someone to actually do the work.  Another possible
option would be to use some kind of automated conversion process.  But I
personally think these solutions are more trouble than they're worth.  So
long as the spacing is consistent within each file, I can live with it.

--Kris

Re: [PHP-DEV] GD vs Imagick

[Kris Craig]

2. Releasing Imagick with PHP means that the release cycles would need

to be sync'ed. This has proven to be inconvenient in the past when an
extension has wanted to change the api, but was forced to wait due to
needed to wait for the next minor/major version of PHP.


Why would they need to be synced?  When PHP releases a new version, can't
we just bundle the latest Imagick build and plug into that?

Sure, having them in sync would yield certain benefits, but none of them
appear to be deal-breakers to me.  Or am I just missing something?

--Kris

Re: [PHP-DEV] Directory separators on Windows

[Kris Craig]

On Mar 30, 2017 8:21 AM, "Sara Golemon"  wrote:
>
> My first thought is UNC paths.  On windows a file server share is
> denoted by \\host\share . if you combine that with relative paths
> produced from PHP, you end up in the dubious situation of
> "\\host\share/path/to/file" <--- wat?
>
> Overall, it smells of magic.
>
> -Sara
>
> On Thu, Mar 30, 2017 at 8:25 AM, Rasmus Schultz 
wrote:
> > Today, I ran into a very hard-to-debug problem, in which paths (to SQL
> > files, in a database migration script) were kept in a map, persisted to
a
> > JSON file, and this file was moved from a Windows to a Linux
file-system -
> > because the paths on the Linux system had forward slashes, the files
> > appeared to be missing from the map.
> >
> > Related questions are very commonly asked by Windows users, indicating
that
> > this is a common problem:
> >
> >
http://stackoverflow.com/questions/14743548/php-on-windows-path-comes-up-with-backward-slash
> >
http://stackoverflow.com/questions/5642785/php-a-good-way-to-universalize-paths-across-oss-slash-directions
> >
http://stackoverflow.com/questions/6510468/is-there-a-way-to-force-php-on-windows-to-provide-paths-with-forward-slashes
> >
> > The answers that are usually given (use DIRECTORY_SEPARATOR, use
> > str_replace() etc.) is that by default you automatically get
cross-platform
> > inconsistencies, and the workarounds end up complicating code
everywhere,
> > and sometimes lead to other (sometimes worse) portability problems.
> >
> > The problem is worsened by functions like glob() and the SPL
directory/file
> > traversal objects also producing inconsistent results.
> >
> > Returning backslashes on Windows seems rather unnecessary in the first
> > place, since forward slashes work just fine?
> >
> > Might I suggest changing this behavior, such that file-system paths are
> > consistently returned with a forward slash?
> >
> > Though this is more likely to fix rather than create issues, this could
be
> > a breaking change in some cases, so there should probably be an INI
setting
> > that enables the old behavior.
> >
> > Thoughts?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Another option would be to create a function that converts all slashes in a
given input string to whatever the directory seperator should be on that
platform.  This way, devs wouldn't have to deal with bulky aliases like
DIRECTORY_SEPERATOR cluttering up their code.

For example:



The above would output "/some/directory" on Linux and "\some\directory" on
Windows.

--Kris

Re: [PHP-DEV] [RFC] Interval Comparison

[Kris Craig]

On Nov 12, 2016 8:21 AM, "David Walker"  wrote:
>
> On Sat, Nov 12, 2016 at 3:08 AM Lauri Kenttä 
wrote:
>
> > On 2016-11-11 19:03, David Walker wrote:
> > >
> > > I took a quick stab at implementing, and had something working for
> > > constant expressions, but handling something akin to:
> > >
> > > $a = 2;
> > > if (1 < $a++ < 3) {
> > > ...
> > > }
> > >
> > > Is a bit awkward in our expansions of : if (1 < $a++ && $a++ < 3).
> > > Seems as if when processing the chain here, you'd need to see if the
> > > left node has a child, and somehow ensure you get the evaluated value
> > > somehow, to override the "left" node.  So logically expansion of the
> > > above would be  if (1 < $a++ && 3 < 3).  I think the same would have
> > > too somehow handle (either by syntax error or something) that if a
> > > non-numeric value creeps into a binary-op-compare we error like:  if
> > > (1 < (2==3) < 3).
> > >
> > > Just some food for thought
> > > --
> > > Dave
> >
> > I don't see how you would ”logically” get 3 < 3. The very point of
> > chaining is that each expression is evaluated only once, so the
> > expression will have the same value in both of the comparisons. So if
> > the first part is 1<2, then the other must be 2<3 (and not 3<3).
> >
> > An expression like a < b < c < d can be currently implemented with
> > temporary variables like this:
> > a < ($tmp1 = b) && $tmp1 < ($tmp2 = c) && $tmp2 < d
> >
>
> That's was the intent in the question I tried to raise with the
> post-increment, as you write `$tmp1 = b`, to my example `$tmp1 = $a++`:
>
> Should
> $a = 1;
> var_dump(1 < $a++ < 3);
>
> (expanded into numbers) be evaluated as:
> 1 < 2 && 2 < 3 - True
> or
> 1 < 2 && 3 < 3 - False
>
> I could see the case for either, although, I would probably prefer the
> latter, as that's what's apparent today, example with
>
> ```
> $a = 0;
> var_dump($a < 1);
> var_dump(++$a < 1);
> ```
>
> Would print out true, false.
>
> Sorry I wasn't overly clear in my statement.
> --
> Dave

+1 on the usefulness of this idea.  I've always wondered why more parsers
don't already support this.

--Kris

Re: [PHP-DEV] RFC proposal for alternative list syntax

[Kris Craig]

On Dec 27, 2015 7:56 PM, "Pierre Joye"  wrote:
>
> On Mon, Dec 28, 2015 at 6:20 AM, Stanislav Malyshev 
wrote:
> > Hi!
> >
> >> // With the new array syntax this has been improved to
> >>
> >> list ($a, $b) = [1, 2];
> >>
> >> // I think this new syntax should logically extend to
> >>
> >> [$a, $b] = [1, 2];
> >
> > list() and array() are two different language constructs, using the same
> > syntax for them is a bad idea.
>
> I tend to agree here but it exists elsewhere and is quite handy. Also
> the behavior of this expression, in this case, is obvious.
>
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

This could be very nice shortcut to have.  Seems intuitive enough; I doubt
there'd be any serious confusion over this.

You should draft an RFC for this, OP.

--Kris

Re: [PHP-DEV] Concept for Json_decode

[Kris Craig]

On Fri, Jul 10, 2015 at 2:39 PM, Larry Garfield la...@garfieldtech.com
wrote:

 On 7/10/15 3:27 PM, Dean Eigenmann wrote:

 Hello,

 I have a proposal for PHP. The proposed interface would allow developers
 to decode json into a custom object directly. If given the approval I would
 possibly be able to implement it.

 Here is my github link with further details:
 https://github.com/decanus/JSON-Aware/tree/master

 Regards,
 Dean


 I'll ask before someone else does...

 Why does this need to be in PHP core?  Why can't it be done purely in
 user-space PHP code?  The syntax would be different, fine, but how is it
 functionally better in C?

 --
 --Larry Garfield


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


PHP already has tons of abstractions designed to provide convenience.
We've never followed the if it can be done in userland, don't do it in
core standard.  If we did, we would have far fewer array_* functions, for
example.

The question is whether or not this would be useful enough to warrant
putting it in core, not whether or not someone could write a ton of code to
do it in userland.

Dean, could you write an RFC for this proposal?  That would make it easier
to evaluate, plus give us something we can vote on.

--Kris

Re: [PHP-DEV] Concept for Json_decode

[Kris Craig]

On Fri, Jul 10, 2015 at 7:07 PM, Larry Garfield la...@garfieldtech.com
wrote:

 On 07/10/2015 07:37 PM, Kris Craig wrote:

 On Fri, Jul 10, 2015 at 2:39 PM, Larry Garfield la...@garfieldtech.com
 wrote:

  On 7/10/15 3:27 PM, Dean Eigenmann wrote:

  Hello,

 I have a proposal for PHP. The proposed interface would allow developers
 to decode json into a custom object directly. If given the approval I
 would
 possibly be able to implement it.

 Here is my github link with further details:
 https://github.com/decanus/JSON-Aware/tree/master

 Regards,
 Dean

  I'll ask before someone else does...

 Why does this need to be in PHP core?  Why can't it be done purely in
 user-space PHP code?  The syntax would be different, fine, but how is it
 functionally better in C?

 --
 --Larry Garfield


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


  PHP already has tons of abstractions designed to provide convenience.
 We've never followed the if it can be done in userland, don't do it in
 core standard.  If we did, we would have far fewer array_* functions, for
 example.

 The question is whether or not this would be useful enough to warrant
 putting it in core, not whether or not someone could write a ton of code
 to
 do it in userland.

 Dean, could you write an RFC for this proposal?  That would make it easier
 to evaluate, plus give us something we can vote on.

 --Kris


 Except that this is simple enough to do in PHP, why does it need to be in
 core has been the reason to reject plenty of proposals, too. It's an
 entirely fair question to ask, and one that an RFC will need to address.


 --Larry Garfield

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


Yes I do agree it's a perfectly fair and legitimate question to ask.  But I
don't agree that it should ever be the sole reason to reject a proposal
unless the convenience that would be added is insufficient to justify it.
That is, admittedly, a subjective standard, but I believe it's the most
fair.

--Kris

Re: [PHP-DEV] Fixing bundled extension version mess

[Kris Craig]

On Tue, Apr 14, 2015 at 7:21 PM, Pierre Joye pierre@gmail.com wrote:

 hi,

 We tried that many times but we fail to handle the version of bundled
 extensions.

 Along with some installer work and other integration (projects
 dependencies management, composer or other), we need to find a way to
 get rid of this problem.

 What do you think to simply use the PHP version number instead of some
 outdated (most of the time) version for all bundled extensions?

 For extensions being available both bundled or externally, the
 external versions will provide a sane version number when installed
 (like timezone db or other).

 Doing so will make requirements management much easier by adding a
 list of core extensions per PHP version.

 Thoughts?

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org

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


Big +1 for this!  It would certainly make things less confusing for many
people.

--Kris

Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

[Kris Craig]

On Thu, Mar 26, 2015 at 3:40 PM, Alain Williams a...@phcomp.co.uk wrote:

 On Thu, Mar 26, 2015 at 10:31:00PM +, Rowan Collins wrote:

  What I've always been annoyed by is the *precedence* of the operator -
 having to add brackets to mix it with string concatenation, etc - which it
 turns out to is the same in all sorts of languages.

 It is the ''all sorts of languages'' that is key here. The point is that
 PHP
 associativity for ?: is different from other languages and it is that that
 confuses and leads to bugs. What is right/wrong is not as important as all
 others doing it the other way.

 --
 Alain Williams
 Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
 Lecturer.
 +44 (0) 787 668 0256  http://www.phcomp.co.uk/
 Parliament Hill Computers Ltd. Registration Information:
 http://www.phcomp.co.uk/contact.php
 #include std_disclaimer.h

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


The feature freeze thing kinda rings hollow for me, as well, because we
were debating this fairly recently before the feature freeze and we still
got pushback from people who feared BC breakage.  This is a bug (whether
we're calling it one or not, it is a bug) and it needs to be fixed.  PHP
does handle it differently, yes, but the different way in which it's
handling it is wrong.  At least, that seems to be the prevailing opinion
among devs.

If we don't put this in 7.0 because of the feature freeze, it needs to go
into the next minor version if the RFC passes.  We should've pulled the
trigger on this before the feature freeze and we shouldn't have to wait
until 8.0 because of that.

--Kris

Re: [PHP-DEV] Only Vote on Votes Initiated After Registration

[Kris Craig]

On Fri, Mar 20, 2015 at 7:30 PM, Pierre Joye pierre@gmail.com wrote:

 hi,

 On Tue, Mar 17, 2015 at 5:01 AM, Philip Sturgeon pjsturg...@gmail.com
 wrote:
  While you can easily question the value or motives of Anthony's post
  about voting irregularities, some simple improvements can be made
  which are uncontroversial. I consider this a low hanging fruit, like
  restricting the sale of firearms to people who are clearly drunk.
 
  I mentioned on that other thread that the FIG has a rule saying you
  cannot cast a vote in any vote that was initiated before your
  membership was activated. That annoyed me a little as I missed out on
  my vote for PSR-1 and PSR-2, but it's a great way to keep some
  potential foul play out of things.
 
  This may not have ever happened.
 
  This will not fix every imagined issue with voting.
 
  If it was happening, it would be bad, right?
 
  Let's just shove that rule in the wiki and call it done.

 To be honest I do not think there are much issues related to this specific
 case.

 However i worry much more about:

 - minimal discussion time before voting
 - actual announces on internals, for discussions phase, voting phase
 and approval
 - avoid changes in a RFC during and after the voting phases but typos

 these are the technical measures I want to implement in the wiki to
 avoid such things to ever happen again. The tricky parts being the
 edition of a RFC during and after voting. While typos could be fine, I
 tend to think that it should not be allowed. One possible way is to
 have the wiki post on internals any changes happening in a RFC during
 or after the votes, so a peer review can happen.

 The time periods limitations are easy to deal with and will ensure a
 clear rule for everyone.

 The announces should be automatic, sent by the wiki, in a way that one
 cannot move from one phase to another and forget to send the announces
 mails.

 On the same note, I would like to get some tech writers involved in
 the RFC process. We have seen some very low quality RFC (the RFC
 itself not necessary the idea behind it). Having tech writers,
 native-like speakers, involved would make the wording and correctness
 of a RFC much less open to interpretations and clear. A side effect,
 it will also the lazy among us to actually use the RFC in a better way
 without being stopped due to some writing issues :)

 Thoughts?

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org

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


I'd be happy to lend a hand with that.

--Kris

Re: [PHP-DEV] Only Vote on Votes Initiated After Registration

[Kris Craig]

On Fri, Mar 20, 2015 at 11:35 AM, Ferenc Kovacs tyr...@gmail.com wrote:

 On Fri, Mar 20, 2015 at 7:14 PM, Philip Sturgeon pjsturg...@gmail.com
 wrote:

  On Mon, Mar 16, 2015 at 2:59 PM, Stanislav Malyshev smalys...@gmail.com
 
  wrote:
   Hi!
  
   when we are fixing the low hanging fruits, please directly put in the
   wiki that the closing time of a vote has to be announced as a UTC time
   so there is no confusion when a day ends.
  
   Good point. I'd still allow other times besides UTC if it's convenient
   to the RFC author, but UTC one should be always present.
  
   --
   Stas Malyshev
   smalys...@gmail.com
  
   --
   PHP Internals - PHP Runtime Development Mailing List
   To unsubscribe, visit: http://www.php.net/unsub.php
  
 
  Is this done yet?
 
 
 I did not have the time to look into this, did anybody else sent a patch
 that I missed?

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu


While I don't want to do anything to impede this fix, I feel compelled to
point out that any proposed changes to the voting RFC have to be voted upon
before they can go into effect.  I think not setting a bad precedent is
worth the inconvenience of doing this by the book.

That said, my vote would be yes.  But we shouldn't be doing an end-run
around the voting process simply because the change is relatively minor;
not when the change is to the voting process itself, at least.

--Kris

Re: [PHP-DEV] Vote process change proposal

[Kris Craig]

On Tue, Mar 17, 2015 at 4:24 PM, Stanislav Malyshev smalys...@gmail.com
wrote:

 Hi!

  I think having clearer rules about what lobbying is permitted, and
  introducing some rules on who can vote on what would be a better way
  of limiting the effect of lobbying.

 And pretty soon we'll have 100-page law codex about rules of campaigning
 and campaign expenditures and what can be said to whom in which place in
 whose presence. All of which of course would be completely unenforceable
 but breed more and more allegations of violations and mistrust and
 gamesmanship. And this is to limit the mythical effect of lobbying the
 existence of which is absolutely without proof. I think this is a
 solution is desperate search of a non-existing problem. Let's just
 recognize lobbying in our case is called discussion and try to make
 it productive instead of disabling it.
 --
 Stas Malyshev
 smalys...@gmail.com

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


I agree that the voting process needs various improvements, censoring who
voted for what is not one of them.  There's nothing wrong with lobbying and
trying to sway voters.  In fact, that's what you're *supposed* to do if you
really care about the given topic.  I wouldn't want to in any way
discourage that.  Transparency is a greater concern, in my view.

If people are just voting based on how a certain person or people voted
every time, or were actually selling their votes in some fashion, that
would be a concern if it were sufficiently widespread, but I'm not aware of
any evidence of that.  But people voting because someone persuaded them to
change their mind, that's not a problem.  It's a sign that the system works
as intended.

This particular proposal seems to me to be a solution in search of a
problem.  I suggest we instead focus on making improvements that would
actually be beneficial.

--Kris

Re: [PHP-DEV] Proposing [constructive] solutions (was: I quit)

[Kris Craig]

On Mon, Feb 16, 2015 at 7:48 PM, Larry Garfield la...@garfieldtech.com
wrote:

 On 02/16/2015 10:31 AM, François Laupretre wrote:


  - The leadership of the language is left to consensus, so that when
 consensus cannot be reached, someone has to take on the role of mediator
 / chairman / leader for the feature, and try to push through a
 compromise.

 I have no democratic solution for this. In the PHP spirit, as Zeev
 explained, if the RFC process doesn't bring a consensus before the vote,
 the discussion should stop and the RFC should be modified. Trying to push
 it to a 2/3 approval while people are fighting is counter-productive. In
 this regard, IMO (and I told her), Andrea should have withdrawn her RFC
 much sooner. It would have allowed to take more time for building the next
 one, and start a new discussion in a more constructive atmosphere. Upcoming
 feature freeze was probably the reason but the result is that we need to
 restart everything from scratch in a bitter atmosphere.


 To be clear: consensus is not leadership.  Consensus cannot be
 leadership.  So the statement leadership of the language is left to
 consensus is a very explicit and deliberate statement that the language
 has no leadership.


On what basis are you making that assertion?  Consensus can be viewed as a
form of group leadership, so long as there are sufficient processes
involved to facilitate that.  It need not necessarily lead to anarchy and
disorder, so I don't think it's necessarily a contradiction in terms.

The problem with having a single leader calling the shots in this case is
that it wouldn't make all the divergent views go away.  Instead, we'd
probably see a good half a billion or so new hooks to PHP emerging as
competing projects.  I think that would be far worse than what we have now,
even though what we have now is far from perfect.



 That is, as I understand it, by design. But let's not pretend otherwise.
 We have a leaderless language and development process, by design, with all
 of the negative side-effects that such a power-vacuum structure entails.

 I'm not saying that as a criticism necessarily. It's just a fact, and we
 shouldn't pretend otherwise.


  - The RFC process traditionally has only one voting phase, with a
 Proof-Of-Concept patch completed, and voters expecting few
 implementation details to change. So a lot of time has to be committed
 to the details of a feature which might be outright rejected. It might
 be more efficient if the principle of a change, details such as syntax,
 and final implementation, could be considered separate phases.

 That's the tradition but I think it is quite open for improvements. While
 we are traditionally using one final vote with multiple options, nothing
 refrains anyone to organize informative pre-votes during discussion to test
 the popularity of a feature before he starts writing code, clearly stating
 that it is not the final vote. This would allow a better information from
 the community to the RFC author. The interest of such running pre-votes is
 that they can contain many more options than the final vote and can be
 started and closed at anytime during discussion. The only requirement is
 that everyone understands that it in *not* the final vote.


 The FIG ran into a similar issue a while back.  The result is a somewhat
 different two-stage RFC process as described here:


 https://github.com/php-fig/fig-standards/blob/master/
 bylaws/004-psr-workflow.md

 It's imperfect, but it does provide extra structure that has been a huge
 improvement over the internals-like free-for-all that preceded it.  In
 particular, it allows members to vote on the concept of a PSR before the
 implementation.  IE, do we want to have a spec dealing with HTTP messages
 is a separate vote from is this particular implementation of an HTTP
 message spec what we want to put our stamp on?

 Additionally, there's a separate spec and meta document.  The meta doc is
 specifically for things like Why did you do X instead of Y? and we
 rejected Z outright for these reasons.  That said, people generally don't
 read the metadoc any more frequently than they read the same notes in
 Internals RFCs today, which often address the issue people are talking
 about for the 5th time. :-(

 An exact replica of FIG's process is probably not going to fly for
 Internals for various good reasons, but it can hopefully serve as a source
 of ideas.


The FIG is a good example of a relatively small group of individuals who
decided to draft their style preferences into a set of standards and tried
to impose that on everyone else by aggressively billing themselves as the
de-facto official standard.  I recall on more than one occasion one of
their organizers posting here trying to get us to endorse their standard as
the official PHP standard.  I've also seen them post on places like
StackOverflow on at least a couple occasions, interjecting on some
unrelated coding question to tell someone their code is 

Re: [PHP-DEV] A modest proposal: __contructStatic

[Kris Craig]

 create the static instance

Isn't that essentially a contradiction in terms?  I can't help but feel
that blurring the line between static and non-static classes/methods would
cause more harm than good.

I've never really done any work with Redis before so I'm also having
trouble understanding the use case for this given that everybody's talking
about this solely in the context of Redis.

--Kris

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

[Kris Craig]

On Thu, Feb 12, 2015 at 10:55 AM, Thomas Punt tp...@hotmail.co.uk wrote:

 Hello PHP Internals!
 I'd like to propose to make empty() a variadic, where if any arguments
 passed in are considered empty, then false is returned - otherwise return
 true.
 My reasoning for wanting this feature is as follows:1)It's a common
 scenario to want to check multiple expressions for empty values. I
 frequently see both of the following pieces of code in projects:#1
 if (empty($a) || empty($b) || empty($c)) {// error here}
 #2if (!empty($a)  !empty($b)  !empty($c)) {// all
 good!}
 Both of the above examples could be shortened if empty() was made to
 accept multiple arguments:#1if (empty($a, $b, $c)) {//
 error here}
 #2if (!empty($a, $b, $c)) {// all good!}
 This creates more compact code that is (in my oppinion, at least) easier
 to read.
 Some code from real-world projects that could benefit from this
 feature:WordPress (one of many):
 https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/template.php#L1963OpenCart:

 https://github.com/opencart/opencart/blob/45fc863fa068d82b5280890e6466a198faa54bff/upload/admin/controller/openbay/ebay_profile.php#L128phpbb:

 https://github.com/phpbb/phpbb/blob/040d451dcca9ae54d8f4b7bdd2f231033765a8f2/phpBB/phpbb/notification/method/jabber.php#L48

 2)Users have brought up the want to pass in multiple arguments into
 empty() before, such as:
 http://stackoverflow.com/questions/4993104/using-ifempty-with-multiple-variables-phphttp://stackoverflow.com/questions/10950470/check-if-multiple-strings-are-empty
 There have been solutions brought up by users to emulate a variadic empty,
 like [1][2], however for unset variables their solutions simply don't work.

 So all in all, it seems like a simple feature to add for a short-hand
 notation of checking multiple expressions for emptiness (which seems like a
 common use-case for users). It has no BC implications and no real downsides
 (at least I couldn't think of any). I have created a patch [3], and if the
 feedback is positive, then I'll create an RFC and submit a PR.
 Thanks,Tom
 [1] http://stackoverflow.com/a/7798842/4530326[2]
 http://icoded.it/php-time-saving-function-to-check-multiple-variables-for-empty-values/[3]
 https://github.com/tpunt/php-src/commit/66c563829775770507147872b98320cdfcb6c51c




I'd say go ahead and draft an RFC with all the details of your proposed
change, then we can discuss and vote on it.  On the surface, it looks like
a useful feature that wouldn't break any existing code.

--Kris

Re: [PHP-DEV] Remove $this from incompatible context

[Kris Craig]

On Thu, Feb 12, 2015 at 8:53 AM, Rowan Collins rowan.coll...@gmail.com
wrote:

 François Laupretre wrote on 12/02/2015 14:56:

 Sorry to get off-topic but could we raise the 'undefined variable' error
 to E_WARNING, at least ? E_NOTICE seems very low for such an error.


 I think the division between E_NOTICE and E_WARNING is a bit arbitrary
 sometimes, but without a good definition of the difference, I think it's
 unhelpful to introduce inflation by raising severities. Don't forget that
 while an undefined variable is sometimes an error, it's sometimes just poor
 coding style, and the user is consciously relying on the implicit null
 (e.g. $count++, or $hash[$key] = $value, or even echo $hash[$key]).

 Perhaps what's needed is a survey of current messages, and an RFC to
 reclassify them based on some consistent definitions?

 Regards,
 --
 Rowan Collins
 [IMSoP]

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


I would also like to see undefined variables escalated to E_WARNING.  Even
though it is often bad coding style, it's also frequently just an oversight
on the part of the developer; an oversight that can lead to unexpected
results.  Since it's very common for environments to display E_WARNING but
not E_NOTICE, some devs-- particularly those who are less experienced in
PHP-- can end up wasting a lot of time trying to chase down the behavior
because they're not seeing any errors.

Besides, making it only an E_NOTICE, we're encouraging people to develop
bad habits that can and do lead to all kinds of problems down the line.  I
know many devs who erroneously believe that declaring variables is actually
discouraged in PHP.  When I point out that not declaring a variable will
throw a notice, they always seem surprised; something along the lines of,
Oh yeah I never see those.

Given the problems that can arise from this, I think that's reasonable
justification enough to make this an E_WARNING instead of E_NOTICE.

--Kris

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Kris Craig]

On Mon, Dec 15, 2014 at 12:11 PM, Stanislav Malyshev smalys...@gmail.com
wrote:

 Hi!

  The fact that it *may* break *some* code that is used somewhere despite
  documentation recommending against it (pretty much deprecating it
  already for years) is a terrible reason not to re-evaluate the situation
  given the huge opportunity to correct this.

 It *will* break some code. There's no chance that somebody somewhere
 doesn't use this. And the change would break it. Worse yet, he won't be
 able to know about it until the customer complains about code logic
 being broken.


On what basis are you making that claim with such certitude?  In all my
years, I have yet to encounter a single, solitary case where someone's
actually relying on PHP's wonky, counter-intuitive, non-standard
associativity with the ternary operator.  If such a one-in-a-billion
scripts does exist somewhere, it's likely some PHP 4 thing that hasn't been
touched in years.



  The only thing that's bonkers here is outright refusal to make trivially
  breaking changes (in addition to numerous other breaking changes already
  accepted) simply for the sake of not breaking some 0.1% of outdated,

 There's not that many breaking changes accepted, and each of them had to
 be substantiated. We had other breaking changes is not a
 substantiation. For example, most uses of associativity are wrong ones
 - is, but that makes the idea of un-associating it even better, since
 unlike changing the associativity, it actually makes the problem obvious
 and easy to fix. Alternatively, of course, we could make a tool that
 detects this and alerts the user, but making it loud still sounds better.
 And the breakage we are discussing is not trivial - it's a logic
 change which makes code silently take different codepath without anybody
 knowing. In the world of BC breaks, this is one of the most evil ones.
 So we should avoid it as much as possible.

  Rather than simply pointing to a 3-year-old close-reason, it would be
  prudent to actually get statistics on how often this unexpected behavior
  is relied upon in large, popular codebases. Packagist  Github, that

 Usually the burden of proof lays on whoever proposes the change. Note
 that a lot of code is not public, especially for languages like PHP that
 is used for websites - meaning, there's little reason to publicize any
 code but reusable library code. And the fact that the change would not
 break a handful of popular libraries doesn't mean it won't break scores
 of websites whose source you can not see, but which are way more
 important for the people using them than some library they don't use.

 Yes, I understand that this means very high burden on somebody proposing
 BC-breaking change, and it makes the development more conservative. It
 is a high burden convince people that this change is worth the risk of
 breaking potentially unknown code with unknown consequences. I think,
 however, it's better than actually suffering these consequences.
 Consider that however ugly this particular wart is, people has been
 living with it for almost 20 years, and it may be preferable for them to
 have somewhat ugly code than having broken code.


I don't think the we've been sick so long we're used to it now argument
is very compelling.  Some BC is expected in major revisions; and,
historically, we have been WAY too conservative about that, in my view.
When there's a major version and there's a BC-breaking change that either
fixes something many people have been complaining about or improves the
language in some other way without losing its identity, it should be a go.
Major revisions are when changes like this are supposed to be made because,
otherwise, these problems remain forever.  I don't think it's rational to
continue to ignore one of the most-requested fixes to PHP because one or
two people out there may be relying on the broken behavior-- and yes, it is
broken in the sense that it does not behave in the manner it's expected to
for a C-like syntax.

Didn't we talk about doing polls before?  We should do a poll on this in
the PHP community and see who, if anyone, has any code anywhere that relies
on this confusingly counter-intuitive behavior.  I would be amazed if even
one person answered yes to that.  So rather than continuing to guess and
make unfounded assumptions, why don't we just ask them and settle the
question here and now?

--Kris


  It's short responses like this and the continued reliance on arguments
  posed in a different era/landscape that compel me to reconsider my
  continued participation in the PHP community at all.

 Sorry, but arguing from do this or that or I'm quitting does not seem
 a very strong argument to me. More drama does not help to evaluate the
 merits of changing the associativity of ?:. I think everybody here
 values the time of the volunteers that continue to contribute to the
 project, but I think keeping the discussion on the technical merits
 would be better.
 --
 

Re: [PHP-DEV] [RFC] PHP 5.7

[Kris Craig]

On Mon, Dec 15, 2014 at 4:20 PM, Andrea Faulds a...@ajf.me wrote:

 Hi Adam,

  On 16 Dec 2014, at 00:15, Adam Harvey ahar...@php.net wrote:
 
  On 15 December 2014 at 16:09, Andrea Faulds a...@ajf.me wrote:
  The RFC can be found here: https://wiki.php.net/rfc/php57
 
  Thanks for the taking the initiative on this.
 
  On timing: I think we should release 5.7 in August (12 months after
  5.6), rather than lining it up with 7.0. This gives us the opportunity
  to then focus our attention on 7.0 entirely for the crucial RC phase
  of that release. Given the limited scope of 5.7, we shouldn't need as
  long a testing cycle.

 That’s a good point, it doesn’t actually have to line up with 7’s release
 and focus on 7.0 RC is crucial given the major changes.

 If others think this is a good idea, I’ll amend the RFC.

 Thanks!
 --
 Andrea Faulds
 http://ajf.me/





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


+1 on this.  I agree with Adam; it'd be better to line up 5.7 with the
support timeline for 5.6 and just handle 7's timeline separately.

--Kris

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Kris Craig]

On Mon, Dec 15, 2014 at 8:19 PM, Leon Sorokin leeon...@gmail.com wrote:

 On 12/15/2014 11:59 AM, Robert Williams wrote:

 What world is this that you live in where every line of code that’s
 written is fully unit-tested


 You took my example too literally; forget the unit tests. Imagine the
 situation differently:

 1. Someone wrote this function:

 function add_five_pct($num) {
   return $num * 1.10;
 }

 2. This function was then used to calculate profit margin and display
 retail prices on your site and business has been great! Unknowingly, you've
 been making 2x what was intended with no ill effects!

 3. A new hire then went through this code on his own accord and decided,
 'wait, this function is a bug!' and took it upon himself to fix it to '$num
 * 1.05'.

 Would you say the e-commerce site has been 'fixed' to work correctly?
 Should the dev be praised for fixing the clearly broken function without
 consulting anyone?

 I cannot come up with a clearer explanation of how a 'silent' code fix can
 foul up the bigger picture in non-beneficial ways. That's the scenario
 that's being discussed here. The main point of contention is, no one knows
 how much code exists in the wild that uses and relies on this misbehavior.
 My argument is 'negligible', others say it's 'non-negligible'. And the
 whole comedy is, no one can actually provide definitive numbers since
 nobody will ever know but a tiny portion of all source code that is out
 there, so all arguments stem from 'meta' evidence and personal experience.


 --
 Leon Sorokin

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


Precisely why I suggested we do a poll and find out.  Polling is a valid
means of getting a reasonable accounting of a particular metric.  If we use
a sufficiently diverse and representative sample, we should easily be able
to get accurate enough results to settle this question once and for all.
The only cost is effort.

--Kris

Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?

[Kris Craig]

On Sat, Dec 13, 2014 at 4:53 PM, Leon Sorokin leeon...@gmail.com wrote:

 Respectfully,

 PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating; the
 utterly ridiculous T_PAAMAYIM_NEKUDOTAYIM argument comes to mind.

  It is not a bug, as the issue's status says: Not a bug.

 I can understand why this would have been a 'wontfix' for versions
 pre-7.0. However, major version changes are done primarily to fix these
 kinds of inconsistencies - that and marketing - and yes they are precisely
 that: bugs. Documentation of unexpected behavior does not make something
 'not a bug'. I and countless other PHP devs simply avoid using these easily
 correctable, useful language features because they are cumbersome,
 unexpected and actively discouraged in the documentation itself; how the
 sum of these facts doesn't qualify as a bug is outside all but the
 narrowest, most bizarre definitions of 'bug' that exists in any software
 community.

 The fact that it *may* break *some* code that is used somewhere despite
 documentation recommending against it (pretty much deprecating it already
 for years) is a terrible reason not to re-evaluate the situation given the
 huge opportunity to correct this.

  It's another one of those bonkers changes. It changes behaviour of
  already existing syntax. This sort of meddling with the language is
  difficult to detect, and there is little value in fixing it. Don't
  piss off users for purety.

 The only thing that's bonkers here is outright refusal to make trivially
 breaking changes (in addition to numerous other breaking changes already
 accepted) simply for the sake of not breaking some 0.1% of outdated,
 against-recommendation code. This is not an argument for purity - I want a
 working-as-expected ternary syntax as a feature, right now it is an
 un-feature and is a caveat that must be documented - it is a wart. If the
 goal was purity, PHP wouldn't even make the list of languages I would
 consider.

 Rather than simply pointing to a 3-year-old close-reason, it would be
 prudent to actually get statistics on how often this unexpected behavior is
 relied upon in large, popular codebases. Packagist  Github, that didnt
 exist significantly in the PHP community in 2012, would be a good place to
 start. It would not even be outside the realm of possibility to do a bit of
 evangelism via Github issues if such cases are found so they can be fixed
 with a 1-year notice.

 It's short responses like this and the continued reliance on arguments
 posed in a different era/landscape that compel me to reconsider my
 continued participation in the PHP community at all.

 cheers,

 --
 Leon Sorokin



 On 12/13/2014 5:20 PM, Derick Rethans wrote:

 On Sat, 13 Dec 2014, Leon Sorokin wrote:

  I was wondering if 7.0 could be the version to fix the long-standing
 incorrect ternary associativity bug in PHP [1].


 It is not a bug, as the issue's status says: Not a bug.

  This seems especially worthy of reconsideration since the Null
 Coalesce RFC has been accepted and merged [2] with the correct
 associativity [3].


 It's another one of those bonkers changes. It changes behaviour of
 already existing syntax. This sort of meddling with the language is
 difficult to detect, and there is little value in fixing it. Don't piss
 off users for purety.

 I suggest you read this too:
 http://derickrethans.nl/bc-dont-be-evil.html

  The major version change seems like the only time to get this done in
 PHP.


 Only time it is *allowed*; that doesn't it should be done.

 cheers,
 Derick



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


Ok I'm going to draft an RFC for this when I have a spare moment.  This is
exactly the sort of contentious issue that the RFC process was created to
help resolve.  We'll bring it to a vote and everyone will make their
arguments.  If 2/3 vote to change the behavior, that'll be that.  I respect
Derrick's position on this but I could not disagree with it more.

--Kris

Re: [PHP-DEV] Add a new flag for json_encode

[Kris Craig]

On Nov 3, 2014 7:13 PM, Juan Basso jrba...@gmail.com wrote:

 Hi,

 I opened a pull request[1] in order to solve the bug 50224[2] and it ended
 creating this pull request to add a new flag called
 JSON_PRESERVE_FRACTIONAL_PART on json_encode function. This flag will make
 the json encode to output float number always with decimal part, even when
 it is 0.

 Currently if you try to convert 10.0 using json_encode it outputs 10. It
 means if you decode it it will give an integer instead a float. In PHP
 words, json_decode(json_encode(10.0)) !== 10.0.

 After some researches and discussions it is not considered a bug because
 JSON specs treat integer and floats as number. Looking how other languages
 treat this encoding I could find it:
 - C (using lib jansson) and Ruby the output contains the decimal portion;
 - Python and Javascript outputs without the decimal portion.

 So it is kind of common to have different behaviors since JSON specs
define
 it as just number. The idea of the new flag is allow PHP to behave the
both
 ways.

 In the pull request Stanislav Malyshev suggested to merge it in the 5.6,
 but just want to see if someone else has any objection. Ferenc Kovacs
 and Jakub Zelenka also are in favor of merging on 5.6.
 Jakub completed suggesting to have this option enabled by default on PHP
7.

 Anyone has any objection on merging it on 5.6? Some comments about
enabling
 it by default in 7?

 As a side note, with the pull request the encode of floats are about 20%
 faster, even after the flag check. This improvement just affect float
 encoding and has no impact on the other types.

 [1] https://github.com/php/php-src/pull/642
 [2] https://bugs.php.net/bug.php?id=50224


 Thanks,
 Juan Basso

Despite some tangential disagreements regarding the default behavior, there
does appear to be a general consensus with regard to the optional argument.

Could you please post an RFC for this if you haven't already?  Thanks!

--Kris

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Kris Craig]

On Sat, Nov 22, 2014 at 2:05 AM, Lester Caine les...@lsces.co.uk wrote:

 On 22/11/14 09:14, Pierre Joye wrote:
  That's why I strongly suggest to make a more realistic time plan and
  stick to it. Specific dates can or should be define later but the
  period (mid october f.e.) should be defined now. One week more when it
  is about fixing one last critical bug for an existing feature is
  perfectly OK, 1 month to actually finish a new feature may not be
  good, at all.

 When a customer tells me I have to give him a completion date I have a
 stock answer. 'When you sign off on the specification'. The current
 problem is that we have no idea just what form PHP7 is going to take,
 and no idea just how much code will need to be reworked as a result.

 There is a lot of parallel developments going on all with different
 goals and in my book all at odds with a cohesive roadmap? Many people
 want their pet features included ASAP but as yet there is no agreement
 even on what PHP7 will be? Until there are a set of goals any planning
 on time is irrelevant.

 It IS all chicken and egg since one can't know now just how long it will
 take to do some of the things being discussed, and it may be that it's
 impossible to achieve a preferred goal in a reasonable time frame? THAT
 is basically what happened with PHP6? The selections made for the goal
 turned out to be the wrong ones but it took time for people to give in
 ad scrap that roadmap.

 From a user point of view I'd rather know what will NOT be part of PHP7
 early, and anything being removed will be tagged as deprecated in PHP5.7
 ... I don't see any way forward without a bridging build to help
 identify code that needs work, and I would like to make a case for NOT
 loading PHP7 down with compatibility switches like e_strict! Lets keep
 the compatibility aspect to PHP5.7 and those of us who don't have time
 to 'upgrade' will continue to run PHP5 for another 10+ years. PHP7
 should be - hopefully - a single clean interface with in my book UTF8
 capability as a bare minimum. But I don't think we need Python3 type
 breaks to achieve this since much of the core has already had UTF8
 sneaked in via the back door. I'm thinking more like a C - C++ break
 where the core procedural framework still works, but people can add OO
 namespaces on top which do not have to be 'required'. I just don't see
 how the 'everything must be exceptions' camp can be accommodated with
 procedural error handling?

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

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


A valid point.  Perhaps, before we decide on a timeline for release, we
should first decide on a timeline for acceptance of new features/etc.  We
should have a cut-off date for RFCs targetted for PHP 7.  After that date
has passed, we gather up all the stuff slated for 7.0 and figure out how
long it will take.  That will yield the timeline we're looking for.  Voting
on a release timeline before then just invites problems and confusion down
the line and would probably force us to ultimately come up with a revised
timeline later on, anyway.  It would be better to do this by the book and
establish a scope cut-off before drafting any timeline for release.

Based on this, as well as flaws in the RFC itself, I'm going to have to
vote no.  Not because I don't support a PHP 7 release timeline, but because
I don't think this RFC at this time is a responsible way to go about doing
it.

--Kris

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Kris Craig]

On Fri, Nov 21, 2014 at 12:18 AM, Joe Watkins pthre...@pthreads.org wrote:

 On Fri, 2014-11-21 at 10:07 +0200, Zeev Suraski wrote:
  After some Twitter hints that I should get my act together and finally
 move
  this to a vote, it’s finally happening:
 
 
 
  https://wiki.php.net/rfc/php7timeline#vote
 
 
 
  Cast your vote!
 
 
 
  Zeev

 Morning Zeev,

 Proposed milestones column needs to change from mid October to
 November.

 Cheers
 Joe


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


Looks good, except I think you should remove the language expressing
opinion about the general merits of backwards compatibility, as that falls
outside the scope of the timeline being voted on.  Plus it's an issue that
really should be discussed and, if needed, voted on separately, not as a
single sentence stuffed into an RFC about a release timeline.  If I were to
vote yes on this timeline, I would not want my vote interpreted as an
endorsement of that position on BC.  I think it's overreach and scope creep
that should be removed.

Other than that one serious (but easily fixable) flaw, I think it's great!

--Kris

Re: [PHP-DEV] [VOTE] [RFC] PHP 7.0 timeline

[Kris Craig]

On Fri, Nov 21, 2014 at 7:10 AM, Zeev Suraski z...@zend.com wrote:

 Kris,

 This existed in the RFC since the get go and I don't believe anybody
 raised any concerns about it.  There was plenty of time for discussion.
 Either way approval of this RFC won't have any effect on the approval or
 rejection of other RFCs.


I have to agree with the concerns raised by Levi and Pierre regarding this
matter.  Regardless of the reasons, too much time has passed since those
discussions for them to really be relevant today, and it does feel a bit
sudden to have this suddenly pop-out for a vote after all this time and
without any warning.

As far as the issue I raised is concerned, didn't I raise that same concern
during the last discussion?  I could be mistaken, but now that you mention
it, I don't think this is the first time I've raised concerns about that.

Besides, the whole I can't focus on that because it's not important
argument just doesn't make any sense to me.  It adds nothing to the RFC and
would literally take like 5 seconds to remove; probably about the same time
it took for you to explain in that email why it wasn't worth removing.  In
any case, I am definitely raising concern about it now and I'm not aware of
any rule saying that's not permitted.  If you like, I'll even fix it for
you with your permission (since it's literally just removing a single
sentence) so you don't have to waste any time/energy dealing with it.


 Kris, All - I'm now on a 7th day straight of a paralyzing 39.5C
 temperature.  Let's focus on what matters.  I at least don't have energy to
 respond to the rest.


Holy shit that sucks!  I can certainly understand your lack of patience in
dealing with issues surrounding this RFC.  Unfortunately, they are
important-- at least, they're important to the people who are raising
them.  It may be prudent for you to find someone you trust to help you
address them given your situation.  Either way, this abrupt vote after such
a long pause does concern me, as does the apparent lack of willingness to
discuss concerns with it.  These are just my opinions, of course, but for
whatever it's worth, I have some serious concerns about this.

--Kris

Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors

[Kris Craig]

On Tue, Nov 18, 2014 at 3:26 PM, Julien Breux julien.br...@gmail.com
wrote:

 I think that it is great time to end to PHP 4 constructors system for PHP
 7.

 IMO, It's a good RFC.


Agreed.  I was going to suggest we throw E_DEPRECATED for 5.x, but you
already have that covered in the RFC.  I don't see anything wrong with this
proposal, in fact.  In hindsight, it probably would've been better if we
had started raising E_DEPRECATED for it back in 5.0, but better now than
never.  We certainly have no obligation to support BC on features that
became obsolete with PHP 4.

+1 on this.

--Kris



 On Wed, Nov 19, 2014 at 12:11 AM, Levi Morrison le...@php.net wrote:

  Dear Internals,
 
  I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If
  accepted, methods with the same name as their defining class will no
  longer be recognized as constructors. As noted in the RFC, there are
  already many situations where we do not recognize these methods as
  constructors, such as in namespaces and traits and when `function
  __construct` is also present.
 
  Andrea Faulds has kindly written a utility that identifies when a PHP
  4 constructor is defined[2]. It does not automatically change the code
  for liability reasons. The utility PHPMD[3] can also detect this but
  has a false positive when `__construct` is also defined.
 
  Cheers,
  Levi Morrison
 
 
[1]: https://wiki.php.net/rfc/remove_php4_constructors
[2]: https://github.com/TazeTSchnitzel/PHP4_Constructor_Finder
[3]:
  http://phpmd.org/rules/naming.html#constructorwithnameasenclosingclass
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 

Re: [PHP-DEV] Thresholds of backwards compatibility breaks

[Kris Craig]

On Wed, Nov 5, 2014 at 10:49 PM, Ferenc Kovacs tyr...@gmail.com wrote:

 2014.11.06. 2:46 ezt írta (Andrea Faulds a...@ajf.me):
 
 
   On 5 Nov 2014, at 20:34, Ferenc Kovacs tyr...@gmail.com wrote:
  
   Regardless of those, I think it would be worse from the users POV than
 our
   current policy where we target no BC breaks in minor/micro versions.
   The only exception should be security concerns (see the unserialize
 changes
   in 5.6 for such an example), which shows that usually BC breaks are
 more
   about the tradeoff, having a BC for a cornercase which probably nobody
 will
   notice but it will simplify the langspec/parser is a different kind of
 BC
   that switching the needle/haystack argument order or removing the
 dollar
   sign would cause.
   Trying to compare or quantify those are hard, and they should be
 decided on
   their own merrit not how much open slot do we have.
  
   Just my 2 cents ofc.
 
  Hmm. Wouldn’t allowing minor BC breaks in minor versions be better than
 having BC breaks only in majors? Is it not easier to make one or two small
 code changes each year, than to do a massive migration every 5 years?

 With major versions you have years to migrate(while we don't cover this in
 our release process rfc, but we tend to keep the previous major version
 alive for years) but I do agree that more frequent but smaller BC breaks
 are better, but I would use that as an argument for having smaller but more
 frequent majors. Like a new major version every 3 years where we provide
 support 2years standard and 1 year security support, so we always have 2
 major branches active, but never have more than two minor versions for a
 major.
 But this probably needs a bit more thought.


It's more than just a matter of time and convenience, though.  It also has
to do with expectations.  There is a predominant expectation that upgrading
minor increments on the same major release branch is essentially safe; that
you won't have to worry about BC breaks-- minor or otherwise-- causing your
code to start failing.  Furthermore, as someone else already pointed out,
major and minor can be very subjective terms and would likely lead to
increased confusion.  Many maintainers would probably opt not to just stay
on their current version rather than risk a BC break that someone here
regarded as minor causing their code to blow-up.  This is especially
problematic given that essential security updates and bug fixes are
frequently included in minor version releases.  It could be argued that
staying current with the latest minor increment on whatever major branch
you're on is more important than being on the latest major increment for
that very reason.  I fear that this proposal would undermine that and erode
the trust people currently have in our minor releases to be BC-friendly,
drastically curtailing the proliferation of critical bug fixes and security
updates.

Historically, we haven't had much trouble on that side of the coin and I'd
prefer to keep it that way.  On the flip side, of course, there is also an
expectation that major increments will have BC breaks and will likely
require updates to your code; which, in turn, leads to the expectation that
adoption of new major version releases will be gradual.  I've often argued
here that we tend to allow known flaws to persist in major version
increments due to an inappropriate level of concern for BC in major release
increments and I still believe that.

That said, this proposal would represent the opposite extreme, making our
minor releases too unreliable in terms of BC for many people's comfort.
Also, the limit of 5 BC breaks seems completely arbitrary.  Why not 6?  Or
4?  There's no rational basis for that number that I can see and it could
potentially tie our hands when faced with a major revision of some kind
that would carry more BC breaks with it.


I do like the idea of having a clear, consistent policy regarding BC and
version increments.  I just don't think the specifics of the proposal are
the right way to go about doing that.

--Kris

Re: [PHP-DEV] Thoughts on the PHP.net website

[Kris Craig]

 I'm not go further into the details of the problems we actually
 have inside that code, as they are very obvious and the source code speaks
 for itself


I'm all for having a discussion about updating the website.  But on the
flip side of that token, you can't just drive by here, suggest a complete
rewrite of the website because the code is bad somehow, then decline to
provide any specific examples.  You need to outline exactly what it is that
you believe is outdated or poorly written, as both could be considered
largely subjective.  Merely stating that they're very obvious does not
constitute a sufficient argument.

Please include details, including the ones you believe to be very
obvious, then we'll talk.  As it stands now, all you've offered is
basically, It's broken.  Go fix it.

--Kris

[PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE?  As far as I can tell, the only way to get these out currently is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

--Kris

Re: [PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds a...@ajf.me wrote:


 On 14 Oct 2014, at 13:47, Kris Craig kris.cr...@gmail.com wrote:

  Hey guys,
 
  Does anybody know why we have $_GET and $_POST, but not $_PUT and
  $_DELETE?  As far as I can tell, the only way to get these out currently
 is
  to parse their values by reading the incoming stream directly.
 
  Is there a reason why we don't want this or is it just that nobody has
  actually written it yet?

 $_GET and $_POST are really misnomers. $_GET is query string parameters,
 $_POST is request body data.

 We should just put the request bodies for all requests, not just POST,
 into $_POST.

 --
 Andrea Faulds
 http://ajf.me/


The problem with that approach though is that it would not be RESTful.  I'm
developing a REST API (with the goal of 100% REST compliance) and having
PUT/DELETE variables mixed in with $_POST would not only be
counter-intuitive, but it would just present a new roadblock.
Incorporating GET in there, as well, would make things even worse.

Basically, if we have $_GET and $_POST, then we should also have $_PUT and
$_DELETE.  Either that, or they should all be tossed.  There's no reason
why $_PUT and $_DELETE should not also exist.

--Kris

Re: [PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

On Tue, Oct 14, 2014 at 6:09 AM, Ben Ramsey b...@benramsey.com wrote:

 On Oct 14, 2014, at 7:47 AM, Kris Craig kris.cr...@gmail.com wrote:

  Hey guys,
 
  Does anybody know why we have $_GET and $_POST, but not $_PUT and
  $_DELETE?  As far as I can tell, the only way to get these out currently
 is
  to parse their values by reading the incoming stream directly.
 
  Is there a reason why we don't want this or is it just that nobody has
  actually written it yet?
 
  —Kris

 This is due to the history of HTML forms sending POST requests with the
 Content-Type application/x-www-form-urlencoded. That is, all the fields are
 key/value pairs and may be easily converted into a PHP array. If you use
 POST with application/json, nothing appears in $_POST, for example.

 In practice, we could support $_PUT and $_DELETE for requests that use
 application/x-www-form-urlencoded, but most folks implementing PUT and
 DELETE do not use application/x-www-form-urlencoded for these requests.

 I would venture to say that most people implementing PUT requests accept
 application/json and most DELETE requests have no body at all. So, $_PUT
 and $_DELETE superglobals wouldn’t make sense.

 -Ben


I'm not following your logic, Ben.  Just because there are a lot of people
out there who don't understand REST, doesn't mean we shouldn't add support
for the other methods.  Besides, if anyone wants to develop a truly RESTful
API in PHP-- which a lot of devs are doing every day-- not giving them
$_PUT and $_DELETE is what wouldn't make any sense.  I'm writing an API now
and the lack of those two globals has proven to be a real pain in the ass.
The Content-Type argument really isn't an issue since the API developer
should be setting the right headers for the request method, anyway.

I don't see any gain in not making those globals available.  All it does is
present both inconvenience and inconsistency for any REST-based project.

--Kris

Re: [PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

On Tue, Oct 14, 2014 at 6:25 AM, Andrea Faulds a...@ajf.me wrote:


 On 14 Oct 2014, at 14:23, Andrey Andreev n...@devilix.net wrote:

  That being said, from a purely semantic prospective, both $_GET and
  $_POST should be tossed - yes. In reality, you can't do that because
  virtually all PHP applications use them. But this is no reason to add
  even more global vars with such misleading ... meanings.

 Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET
 and $_POST then. Because they’re aliases (by-reference superglobals),
 there’s no additional memory consumption, but we finally have saner names.
 --
 Andrea Faulds
 http://ajf.me/


I don't think that would be a good idea, either.  They require more typing
and it'd probably be a lot easier for devs to remember which one means GET
and which one means POST.

The fact that $_PUT and $_DELETE aren't necessary because we can use other
approaches to get that data is irrelevant.  Having globals for two REST
methods but not the other two is very counter-intuitive from a dev
standpoint.  We just recently discussed how PHP tends to have duplicate
ways of doing something in order to make it as easy as possible.  I believe
this is one of those times.  It would make it a lot easier for devs,
particularly the ones less experienced with REST, to create APIs that
actually use the correct methods without running into the confusion over
why there's a $_GET and a $_POST but not a $_PUT or a $_DELETE.

PHP is supposed to be KISS, right?  Well, the current reliance on
php://input for two methods but not the other two invites confusion.  That
makes it less-than simple, I believe.

Removing or renaming $_GET and $_POST would also create confusion and
almost certainly cause widespread BC breakage on a pretty massive scale.
And there's really no gain to offset that.  So that just leaves us with
either continuing to have two REST methods but not the others or add a
$_PUT and a $_DELETE, even if they just alias to php://input again.

--Kris

Re: [PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan m...@mjdugan.com wrote:


 On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote:


 On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote:

  $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

 Ew, non-superglobals.

 But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY
 (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes
 sense, but isn’t too long:

 * $_QUERY - query string parameters
 * $_BODY - request body parameters
 * $_REQUEST - query string and request body parameters

 Makes more sense than $_GET and $_POST.

 Any objections?

 --
 Andrea Faulds
 http://ajf.me/


 +1 for this. This would hopefully also eliminate the confusion for new
 developers (or not-so-new developers) who don’t quite understand that $_GET
 and $_POST don’t strictly relate to their HTTP verbs of the same name.

 --

 Mike Dugan

 m...@mjdugan.com


That could work, though the BC breakage will be extreme.  I'm not sure if
that's worth it even in a major version increment.  On the other hand,
making $_PUT and $_DELETE available wouldn't break anything and wouldn't
require re-training for devs.

--Kris

Re: [PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

On Tue, Oct 14, 2014 at 6:47 AM, Andrea Faulds a...@ajf.me wrote:


 On 14 Oct 2014, at 14:42, Kris Craig kris.cr...@gmail.com wrote:

  I don't think that would be a good idea, either.  They require more
 typing
  and it'd probably be a lot easier for devs to remember which one means
 GET
  and which one means POST.

 I’ve already proposed the shorter $_QUERY and $_BODY.

  PHP is supposed to be KISS, right?  Well, the current reliance on
  php://input for two methods but not the other two invites confusion.
 That
  makes it less-than simple, I believe.
 
  Removing or renaming $_GET and $_POST would also create confusion and
  almost certainly cause widespread BC breakage on a pretty massive scale.

 I never said anything about removing $_GET or $_POST. I suggested adding
 saner aliases.


Ok, that was my bad.  I misinterpreted.



  And there's really no gain to offset that.  So that just leaves us with
  either continuing to have two REST methods but not the others or add a
  $_PUT and a $_DELETE, even if they just alias to php://input again.

 Adding $_PUT and $_DELETE is silly.


No more silly than $_GET and $_POST are now.  But either way, we should try
to make things consistent.  This inconsistency only serves to invite
confusion.


 We already have a nonsensical system where $_GET isn’t about GET, but
 about query string parameters, and $_POST isn’t about POST, but the request
 body. We should create sane aliases ($_QUERY and $_BODY) and extend
 $_POST/$_BODY to support request bodies from any method.

 This would make things actually simpler, and less confusing, as we stop
 pretending $_GET is about GET and $_POST is about POST. By using $_QUERY,
 it’s clear it’s about query string parameters, which any method can have.
 Similarly, by using $_BODY, it’s clear it’s about request body parameters,
 which any method can also have.


That's a good point.  Unfortunately, $_GET and $_POST aren't going away
anytime soon.  And in the meantime, we should at least have $_PUT and
$_DELETE alias to $_POST so devs have the option of using them.


 Sure, all existing code uses $_GET and $_POST and they won’t go away any
 time soon. But we would have saner names that people writing new code can
 use.

 --
 Andrea Faulds
 http://ajf.me/

Re: [PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright c...@daverandom.com wrote:

 On 14 October 2014 14:46, Kris Craig kris.cr...@gmail.com wrote:
  On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan m...@mjdugan.com wrote:
 
 
  On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote:
 
 
  On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com
 wrote:
 
   $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.
 
  Ew, non-superglobals.
 
  But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY
  (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes
  sense, but isn’t too long:
 
  * $_QUERY - query string parameters
  * $_BODY - request body parameters
  * $_REQUEST - query string and request body parameters
 
  Makes more sense than $_GET and $_POST.
 
  Any objections?
 
  --
  Andrea Faulds
  http://ajf.me/
 
 
  +1 for this. This would hopefully also eliminate the confusion for new
  developers (or not-so-new developers) who don’t quite understand that
 $_GET
  and $_POST don’t strictly relate to their HTTP verbs of the same name.
 
  --
 
  Mike Dugan
 
  m...@mjdugan.com
 
 
  That could work, though the BC breakage will be extreme.  I'm not sure if
  that's worth it even in a major version increment.  On the other hand,
  making $_PUT and $_DELETE available wouldn't break anything and wouldn't
  require re-training for devs.

 ...but is also the wrong solution. It's not scalable,


How is it not scalable, exactly?  It's just a couple aliases.


 and the only
 sensible way to implement them would be as aliases of $_POST, because
 they would contain the same data. How does this fundamentally differ
 from $_BODY (or whatever)?


It's not supposed to functionally differ.  It's supposed to create some
better consistency and make it easier for devs to differentiate between
different REST methods when retrieving data.  If REQUEST_METHOD is PUT,
then I can set the parsed params to the value of $_PUT.  The aliases match
the methods used, making the code that much more readable and scalable.

--Kris

Re: [PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

On Tue, Oct 14, 2014 at 1:21 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:

 On 10/14/2014 11:16 AM, Rowan Collins wrote:
  On 14/10/2014 17:18, Rasmus Lerdorf wrote:
  I think 20+ years of history has proven this to be a non-issue. Of all
  the things that people get confused by in PHP, $_GET/$_POST are right
  near the bottom of the list.
 
  The popularity of REST is what has changed this. Until people started
  writing RESTful APIs, only two HTTP request types were in common use.
  Nobody was confused about where PUT method data would end up, because
  nobody processed any PUT methods.
 
  It makes no sense to me to make $_BODY an alias for $_POST. $_POST
  implies the default body encoding that a broswer performs on a POST
  request. Making an alias called $_BODY that doesn't contain the body of
  a request unless it is POST-encoded would be super confusing.
 
  The encoding has no relationship with the request type, even in browsers
  - the default encoding of a POST form is actually the same encoding used
  to produce a URL form a GET form.

 Sure, but $_GET/$_POST do. They were not named to match HTTP primitives.
 They were named to match form methods. As in form method=get and
 method=post. And here the default encoding the browsers use for these
 two methods definitely matter.

 -Rasmus


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


I understand that that was the original intent. However, the use cases have
expanded beyond simply handling HTML form submissions.  People are writing
REST APIs using PHP now, and having GET/POST but not PUT/DELETE has indeed
led to confusion.  I only posted this after doing a Google search and
finding tons of results from people mistakenly asking why PHP doesn't
handle PUT/DELETE requests or complaining how the lack of aliases for
PUT/DELETE leads to inconsistency in the code.

Personally, I like the idea of using more appropriately named aliases,
particularly if they're roughly the same number of characters.  However, we
would need to allow at least several years for people to adopt the new
globals before deprecating $_GET and $_POST.  Ultimately, they will either
need to be deprecated or the $_PUT and $_DELETE aliases will need to be
added, otherwise the issue I raised would remain unresolved.

--Kris

Re: [PHP-DEV] New globals for PUT and DELETE

[Kris Craig]

On Oct 14, 2014 3:44 PM, Park Framework park.framew...@gmail.com wrote:

 I also implement RESTFul projects, argue need to modify PHP to make it
 convenient for RESTFul :)

 The problem is not in the names of global variables, the problem is a
 lack of data they, if method request PUT, DELETE.

 But there is nothing wrong with the renaming and adding aliases,
 rename $HTTP_GET_VARS, over time, are used to and have begun to use

 2014-10-15 1:21 GMT+03:00 Zeev Suraski z...@zend.com:
  -Original Message-
  From: Park Framework [mailto:park.framew...@gmail.com]
  Sent: Wednesday, October 15, 2014 1:16 AM
  To: Zeev Suraski
  Cc: Kris Craig; Rasmus Lerdorf; Rowan Collins; PHP internals list
  Subject: Re: [PHP-DEV] New globals for PUT and DELETE
 
  2014-10-15 0:56 GMT+03:00 Zeev Suraski z...@zend.com:
 
   PHP today to enable successful  easy implementation of RESTful
  interfaces.
 
  No, now PHP not successful  not easy implementation of RESTful
  interfaces.
 
  Projects like Apigility beg to differ.
 
  Zeev

It is worth noting that nearly all APIs that claim to be RESTful are not.

--Kris

Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7

[Kris Craig]

On Oct 12, 2014 12:54 AM, Derick Rethans der...@php.net wrote:

 On Sat, 11 Oct 2014, Kris Craig wrote:

  On Oct 11, 2014 1:52 PM, Nikita Popov nikita@gmail.com wrote:
  
   We currently have a number of deprecated features, which we likely
   want to remove in PHP 7. I've created a tracking RFC listing
   deprecated functionality (if I missed something, please tell):
  
   https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
  
   I expect many of these are no-brainers (like assigning new
   by-reference), but other items like removal of ext/mysql may need
   additional consideration.
  
   Unless there are items that are particularly contested, I'd like to
   handle the bulk of these in a single vote and only have separate
   votes for ext/ereg and ext/mysql, as these are arguably more
   intrusive.
 
  +1 on all of that.
 
  As far as ext/mysql is concerned, I would eagerly vote in favor of
removing
  it.  It performs poorly, is procedural, less secure, doesn't support

 is procedural is however, never a reason to remove something. As most
 of PHP's function library, is procedural and works just fine.

Fair point.  I agree that alone wouldn't be grounds to remove it.  I was
just citing that as one of many deficiencies compared to more current
extensions like ext/mysqli.

--Kris


 Derick

 --
 http://derickrethans.nl | http://xdebug.org
 Like Xdebug? Consider a donation: http://xdebug.org/donate.php
 twitter: @derickr and @xdebug
 Posted with an email client that doesn't mangle email: alpine

Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7

[Kris Craig]

On Oct 11, 2014 1:52 PM, Nikita Popov nikita@gmail.com wrote:

 Hi internals!

 We currently have a number of deprecated features, which we likely want to
 remove in PHP 7. I've created a tracking RFC listing deprecated
 functionality (if I missed something, please tell):

 https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7

 I expect many of these are no-brainers (like assigning new by-reference),
 but other items like removal of ext/mysql may need additional
consideration.

 Unless there are items that are particularly contested, I'd like to handle
 the bulk of these in a single vote and only have separate votes for
 ext/ereg and ext/mysql, as these are arguably more intrusive.

 Thanks,
 Nikita

+1 on all of that.

As far as ext/mysql is concerned, I would eagerly vote in favor of removing
it.  It performs poorly, is procedural, less secure, doesn't support
prepared statements, etc.

It's always annoyed me how sites like w3schools still teach people to use
ext/mysql.  It's been deprecated for quite awhile now and I think it's time
to pull the plug on it.

--Kris

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

[Kris Craig]

On Fri, Oct 10, 2014 at 1:34 PM, Andrea Faulds a...@ajf.me wrote:


 On 10 Oct 2014, at 21:27, Marco Pivetta ocram...@gmail.com wrote:

  While rambling with some code today, I realized that `call_user_func`
  behaves strangely, appearing and disappearing from stack traces depending
  on versions of PHP. For an example, compare
  http://3v4l.org/fGpIk#vphp7@20140901, http://3v4l.org/fGpIk#v530 and
  http://3v4l.org/fGpIk#vhhvm-301.

 IIRC this is a bug caused by PHP7 eliminating the call to the function
 entirely, and instead inserting a normal function call opcode. See:
 https://github.com/php/php-src/blob/292421d3a1fcefe88c3017ffdb9f889c39a6c8c1/Zend/zend_compile.c#L2777

 This could possibly be fixed somehow.

  Additionally, it seems like `call_user_func` and similars are impacting
  performance in some parts of my codebase (event dispatcher logic).

 In PHP 7, due to the function call removal, it should be just the same,
 performance-wise, as a normal function call.

  Therefore, here comes my idea of simply getting rid of `call_user_func`,
  `call_user_func_array`, `func_get_args`, `func_num_args` and
 `func_get_arg`.
 
  My plan for it would be to add a deprecation (notice? not sure about
 that)
  in PHP 5.7, and a complete removal of those methods in PHP 7.0.
 
  BC compatibility is easily achieved as variadics (
  https://wiki.php.net/rfc/variadics) allow for writing cleaner and less
  complex versions:

 “Easily” achieved? No. This would break an awful, awful lot of existing
 PHP code with no gain. There’s no need to deprecate it any time soon. The
 variadics syntax is merely a nicer alternative. We should not force people
 to rewrite existing code to use it. There is absolutely no need to get rid
 of func_get_args.

 I would vote against any such proposal, and I hope others on the list
 would join me in doing so.

 --
 Andrea Faulds
 http://ajf.me/





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


Agreed.  The call_user_func() and call_user_func_array() functions are used
all over the place.  I see absolutely no gain, whatsoever in removing them
and forcing developers to write their own userland variants instead.

--Kris

Re: [PHP-DEV] [PHP7] Remove the function keyword from class methods?

[Kris Craig]

On Oct 4, 2014 11:24 AM, Thomas Gossmann m...@gossimaniac.net wrote:

 Thanks Johannes, I slipped over it but would have never found the
discussion to it.

 I run over it and the summary is: Many people like it and those that
don't have brought arguments, that are present here again. The discussion
is almost 4 years old by now, and people are complaining over things
getting implemented in php back in time, which are now implemented and
turned out to be ok - I expect the same to happen with this idea.
 Main contra argument is, people are not able to grep for 'function *'
anymore, which I guess is a minority of people and they can write
themselves a shell-script which makes it possible to search for functions
again, so not a big deal. However, the more important statement behind this
is, who is the more important crowd of people that are targeted with
changes like these? Primary or secondary consumers?
 ... but see my other mail, which conatains answers.

 Though, I have one question left regarding the old rfc? Why it has been
gone inactive and basically slept since then?

 Thanks
 Thomas Gossmann

 Am 04.10.14 um 19:44 schrieb Johannes Schlüter:

 On Fri, 2014-10-03 at 18:21 +0200, Thomas Gossmann wrote:

 I guess this was a discussion earlier, though I wasn't able to find
 anything about it. Would love to hear, what pdt-internals (re-)think
 about that topic.


 Go to wiki.php.net/rfc look at the titles containing function and you
 will see Make T_FUNCTION in method declarations optional which was
 added by me. https://wiki.php.net/rfc/optional-t-function

 Since proposing I was convinced this wasn't good. Please bring new
 arguments. Discussion was in this thread
 http://news.php.net/php.internals/50628 (another viewer might be better
 to find the ~64 followups)

 johannes



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


Summary thus far:

Pro:  Eliminating the function keyword is good because coding ===
sculpting; perfection occurs when there's nothing left to remove.

Con:  It's completely unnecessary and would make it prohibitively difficult
to consistently locate subroutine declarations in a codebase.

I believe the cons vastly outweigh the pros in this case.  The function
keyword is a very good example of PHP's KISS (Keep It Simple, Stupid)
philosophy.

But if you're serious about this, draft an RFC and we'll vote on it.  If
2/3 support your idea, it'll pass.

--Kris

Re: [PHP-DEV] [PHP7] Remove the function keyword from class methods?

[Kris Craig]

On Fri, Oct 3, 2014 at 1:00 PM, Arvids Godjuks arvids.godj...@gmail.com
wrote:

 Hello internals.

 I'm firmly against removing the function keyword. PHP is a dynamic
 language, that means that even using the latest most functional IDE's out
 there, finding the implementation is not always few clicks away (PhpStorm's
 Find Usages) and you need to do a search in the project. And the only
 thing, that makes it fast and easy, is the function keyword, because you
 can do a search by function nameISearchFor and get a single hit.

 I'm not even mentioning the code readability...


While there are reasonable arguments to be made for removing it, I agree
that it would create more problems than it would solve.  Specifically, one
of the things I've always liked about PHP is that I can always track down a
particular method declaration in a codebase by simply doing a grep for the
word function preceding the name.  If it's defined in that codebase,
it'll come up.  Even making the keyword optional would eliminate that
certainty and make it that much more difficult to navigate an unfamiliar
codebase.

--Kris

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Kris Craig]

On Tue, Sep 30, 2014 at 12:59 PM, Andrey Andreev n...@devilix.net wrote:

 On Tue, Sep 30, 2014 at 10:31 PM, Sharon Levy iam4webw...@hotmail.com
 wrote:
 
 
  From: Andrey Andreev n...@devilix.net
  Sent: Sep 29, 2014 3:01 PM
  To: Sharon Levy sle...@pipeline.com
  Cc: Zeev Suraski z...@zend.com, Derick Rethans der...@php.net,
 Andrea
  Faulds a...@ajf.me, PHP internals internals@lists.php.net
  Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on
  RFCs?
 
  On Tue, Sep 30, 2014 at 12:28 AM, Sharon Levy sle...@pipeline.com
 wrote:
 
   I think in all fairness, users should be required to learn C and
 pass a
   test
   demonstrating basic knowledge of PHP's internals in order to acquire
   voting
   privileges.
  
  So, in order to vote, users should become (capable of being) core
  contributors? :)
  How does that change anything?
  
  Cheers,
  Andrey.
 
  ... the important truths, that knolege is power, that knolege is safety,
  and that knolege is happiness.  -- Thomas Jefferson
 
  If more users were educated about PHP's internals, then there could be
 more
  substantive discussions between Userland and core contributors, including
  better ideas originating from Userland. More users might even consider
  becoming core contributors.  It would change the status quo.
 

 Well, let's see ... what is the current status quo?

 Currently, all voters have VCS accounts, meaning that they already are
 at least one of:

 a) C code contributors
 b) documentation contributors
 c) contributing to the php.net website or something else but similar

 It is written somewhere that maintainers of popular userland
 frameworks and tools _could_ get voting privileges, but the voters
 from this group are voters because they already have VCS accounts for
 other purposes. It is otherwise undefined how that happens - this is
 as close as you can get to the meaning of status quo as far as
 userland people are concerned.

 What this basically means is that currently you ARE required to either
 know C and PHP's internals, or to take care of all the not really fun
 (for a programmer) stuff that surrounds it.
 It that hasn't encouraged more people to contribute, how would taking
 away non-C-contributors' votes be an encouragement? If I was a php-doc
 contributor, that would be you showing me the middle finger, not
 encouragement.

 Sure, it would change the status quo, but for the worse.

 Cheers,
 Andrey.

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


+1 I agree completely.

This discussion has raised another issue though that I think merits further
consideration:  What standards do we use to give VCS accounts-- or karma,
for that matter.  As many have pointed out already, we don't currently have
a consistent, quantifiable standard for either of these.  This can lead to
some people getting VCS creds who may not have actually done anything to
merit that, at least according to some people here.  Likewise, there is no
specific standard for giving people karma; just a vague understanding that
those who contribute enough will eventually maybe get it.

If you want to tackle the problem of new people not being motivated to
contribute, that's probably the #1 (or maybe #2, behind the steep learning
curve) reason why there's an absense of fresh faces submitting code.  As
someone who has been a project manager over the years, I can tell you that
nothing motivates people more than giving them set goals to achieve and
rewards for achieving them.  For example, if you contribute x number of
patches, resolve y number of bugs, z number of pull requests, etc, you'll
qualify for basic karma.  That would provide a quantifiable incentive and I
guarantee you we'll get people who will start contributing in order to meet
that goal and get that feather in their cap.  Right now, most people don't
even know who grants karma, how to request it, or when it's appropriate to
request it.  The current, Just contribute steadily over time and we'll
see message may have the advantage of giving us greater discretion, but it
does nothing to motivate people to participate.

As far as VCS access goes, having specific metrics like that probably
wouldn't be feasible since it's much more of a case-by-case basis sorta
thing.  We could establish some general guidelines, though.  To prevent VCS
accounts from being given out frivolously, as some have complained, I
suggest we treat each qualifying VCS request as an RFC.  The person
(sponsor?) who thinks they should be added adds an RFC, outlining the
person's experience and why s/he qualifies for VCS access.  Then we vote
and simple majority wins.

I think it would be beneficial for us to draft an RFC that establishes
these changes.  That way, we can address the concerns raised by those who
believe that VCS-- and, with it, voting rights-- is being given out too
easily, while also maintaining the inclusiveness of the current voting
system.  It 

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Kris Craig]

On Mon, Sep 29, 2014 at 3:01 PM, Andrey Andreev n...@devilix.net wrote:

 On Tue, Sep 30, 2014 at 12:28 AM, Sharon Levy sle...@pipeline.com wrote:
 
  ...
 
  I think in all fairness, users should be required to learn C and pass a
 test
  demonstrating basic knowledge of PHP's internals in order to acquire
 voting
  privileges.

 So, in order to vote, users should become (capable of being) core
 contributors? :)
 How does that change anything?

 Cheers,
 Andrey.

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


Which is better, Democracy or Meritocracy?  Perhaps some combination of
both?  Either way, it's a difficult question with no perfect answers.

--Kris

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Tue, Sep 23, 2014 at 12:24 AM, Michael Wallner m...@php.net wrote:

 On 2014-09-23 06:00, Sanford Whiteman wrote:
  What would happen is it'd throw an E_DEPRECATED for at least the
 remainder
  of 5.x, then throw the usual E_WARNING for a missing argument starting
 in
  7.x with no default.
 
  Sounds OK to me now that I've noticed this:
 
  https://bugs.php.net/bug.php?id=68081
 
  Pretty sure that's a sane report, and it's enough to make me say
  checkdnsrr() doesn't work now at all.


 Given that this function is over 16 years old [1] and guessing that it
 was used as a simple kind of email domain verification, I think
 checkdnsrr() works as expected [2], [3].

 [1] http://marc.info/?l=php-internalsm=90222489331812w=2
 [2] http://tools.ietf.org/html/rfc2821#section-5
 [3] http://tools.ietf.org/html/rfc5321#section-5.1

 --
 Regards,
 Mike


Except that it doesn't work as expected because most devs (including
myself) aren't readily familiar with posts from 1998.  And even if that
were its purpose back then, that really has no relevance today, as the
purpose and identity of PHP itself has evolved drastically since then.

If that really is a concern, though, then I would propose getting rid of
checkdnsrr() altogether (or making it an alias of checkmxrr()) and creating
a new general-purpose DNS lookup function that returns a boolean.  Of
course, I really don't think that's necessary since this stuff from 16
years ago doesn't have any meaningful bearing on how it's being used today
by modern PHP developers.

--Kris

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Tue, Sep 23, 2014 at 12:38 AM, Michael Wallner m...@php.net wrote:

 On 2014-09-23 09:30, Kris Craig wrote:
 
 
  On Tue, Sep 23, 2014 at 12:24 AM, Michael Wallner m...@php.net
  mailto:m...@php.net wrote:
 
  On 2014-09-23 06:00, Sanford Whiteman wrote:
   What would happen is it'd throw an E_DEPRECATED for at least the
  remainder
   of 5.x, then throw the usual E_WARNING for a missing argument
  starting in
   7.x with no default.
  
   Sounds OK to me now that I've noticed this:
  
   https://bugs.php.net/bug.php?id=68081
  
   Pretty sure that's a sane report, and it's enough to make me say
   checkdnsrr() doesn't work now at all.
 
 
  Given that this function is over 16 years old [1] and guessing that
 it
  was used as a simple kind of email domain verification, I think
  checkdnsrr() works as expected [2], [3].
 
  [1] http://marc.info/?l=php-internalsm=90222489331812w=2
  [2] http://tools.ietf.org/html/rfc2821#section-5
  [3] http://tools.ietf.org/html/rfc5321#section-5.1
 
  --
  Regards,
  Mike
 
 
  Except that it doesn't work as expected because most devs (including
  myself) aren't readily familiar with posts from 1998.  And even if that
  were its purpose back then, that really has no relevance today, as the
  purpose and identity of PHP itself has evolved drastically since then.
 
  If that really is a concern, though, then I would propose getting rid of
  checkdnsrr() altogether (or making it an alias of checkmxrr()) and
  creating a new general-purpose DNS lookup function that returns a
  boolean.  Of course, I really don't think that's necessary since this
  stuff from 16 years ago doesn't have any meaningful bearing on how it's
  being used today by modern PHP developers.

 Phew, modern or rather unaware or uneager to research?
 Anyway, I'm done with this topic; I don't see any reason for action,
 except maybe, improving related documentation.


 --
 Regards,
 Mike


Wow that got personal really fast.  I was just saying that, when most devs
look-up a function on php.net, they don't also then search Google for any
decades-old references that might yield some additional insight on the
origin story of the function.  I don't think that means they're not
intellectually curious.

--Kris

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote:

 hi Kris,

 On Sat, Sep 20, 2014 at 4:15 AM, Kris Craig kris.cr...@gmail.com wrote:
  Per discussion in an earlier thread.  Here's the RFC:
 
  https://wiki.php.net/rfc/checkdnsrr-default-type
 
 
  Basically, this RFC seeks to make it so that PHP's checkdnsrr()
function,
  which is most commonly used to see whether or not a hostname exists, no
  longer restricts itself to only MX records by default.
 
  Though the RFC itself is a no-brainer, the more difficult question is
which
  solution should be implemented.  The two options currently presented are
  changing default from MX to ANY, which would cause it to check all
  records and not just MX; and getting rid of the default altogether and
  making it so that the argument is required.
 
  From what I can tell, there are valid arguments to be made for both, so
I
  would love to see some discussion/debate here regarding which solution
  should be implemented, as I'm currently undecided.  Also please feel
free
  to point out any areas of improvement for the RFC itself.

 I am not sure which problem this RFC tries to solve, do you have any
 example showing the issues please?

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org

It's not a bug or anything.  The problem is that the current behavior is
very counter-intuitive, not to mention unnecessary because there's already
another function dedicated to MX lookups.

At my job, we wasted a good deal of time troubleshooting what appeared to
be a weird DNS issue that turned out to just be a checkdnsrr() lookup that
was looking only for MX records because a second argument wasn't passed.  I
cannot think of any use case served by this behavior.

--Kris

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Sep 22, 2014 1:09 AM, Pierre Joye pierre@gmail.com wrote:

 On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig kris.cr...@gmail.com wrote:
 
  On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote:

 Well, for what I can see users already take into account this part of
 the issue then:

 https://github.com/search?l=phpq=checkdnsrrtype=Codeutf8=%E2%9C%93

 changing the default will make create code compatibility between 5.x
 and 7.x, killing the gains we may have by changing the default.

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org

That's why we have the option of just making that arg required without a
default, which would be targetted for PHP 7.

--Kris

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Sep 22, 2014 2:16 AM, Pierre Joye pierre@gmail.com wrote:

 On Mon, Sep 22, 2014 at 10:56 AM, Kris Craig kris.cr...@gmail.com wrote:
 
  On Sep 22, 2014 1:09 AM, Pierre Joye pierre@gmail.com wrote:
 
  On Mon, Sep 22, 2014 at 9:07 AM, Kris Craig kris.cr...@gmail.com
wrote:
  
   On Sep 21, 2014 11:52 PM, Pierre Joye pierre@gmail.com wrote:
 
  Well, for what I can see users already take into account this part of
  the issue then:
 
  https://github.com/search?l=phpq=checkdnsrrtype=Codeutf8=%E2%9C%93
 
  changing the default will make create code compatibility between 5.x
  and 7.x, killing the gains we may have by changing the default.
 
  Cheers,
  --
  Pierre
 
  @pierrejoye | http://www.libgd.org
 
  That's why we have the option of just making that arg required without a
  default, which would be targetted for PHP 7.


 I got that :)

 but now imagine one doing the following call now:

 checkdnsrr(myhost)  == TRUE

 where only MX was set and we suddenly change the default to ANY but
 ANY does not include MX, then the validation will simply fail and the
 code will become either:

Why doesn't ANY include MX?  That also seems counter-intuitive, as one
would assume that ANY would check for any type of record.


 checkdnsrr(myhost, 'MX')  == TRUE

 and for what I see, most of the usages are done to valid emails.

Hmm that hasn't been my experience, but regardless, they should be using
checkmxrr() for that, anyway.  As it stands now, the default behavior of
checkdnsrr() just redundantly mirrors the behavior of another function and
for no apparent reason.


 I am not saying I am against such changes, I only do not see the gains
 but the possible pains in a couple of situations, these pains will
 make migration harder with no technical gains from our side.

I do think it would be a usability gain, if not a technical one.  And I've
long been of the opinion that major version increments like PHP 7 are the
ideal time to implement such improvements, even despite some potential
edge-case BC.

What if we got rid of the option to change the default and instead just
went with making both args required?

--Kris


 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Kris Craig]

On Sep 22, 2014 8:39 AM, Johannes Schlüter johan...@schlueters.de wrote:



 On September 22, 2014 4:21:29 PM CEST, Rafael Kassner kass...@php.net
wrote:
 IMHO, denying non-karma people to vote is like to making PHP a
 company's
 product, or, in another words, you use what we built and shut up,
 because
 only listening people won't allow to accept/deny a particular RFC, only
 votes do. People surely don't comment (myself included) why they are
 choosing some particular option on a RFC, but they are making their
 opinion
 count, and I think this kind of democracy power shouldn't be voided.

 Slightly provocative:  Why should I be forced to maintain code by people
who
 don't want to maintain it themselves?

Nobody is forcing you to do anything.  You choose to contribute to PHP in
the manner in which you do, just as other people choose to contribute in
different, sometimes less obvious, ways.

Probably even due to votes by people
 about whom I don't know anything? Mind that most maintenance work by
 most contributors happens in free time on a voluntarily base.

 And no open source doesn't mean democracy as governing model.

It can.  Every project is governed differently.

Winston Churchill once famously said that democracy is the worst form of
government, except all the others that have been tried.

The
 democratic part is that people who don't like it can fork the project and
 eventually receive a higher traction.

And then we can have dozens of competing PHP codebases floating around.

But no, one man one vote and full
 equality doesn't work out. (i.e. if a modules primary maintainer vetos a
 change I have to mind that [which doesn't mean I have to agree in the
 end])

 Using separated voting count isn't an option? Like only internal
 changes
 are voted only by people with karma and features/changes/small BC
 breaks
 that affects userland are allowed to anyone. This way I believe is easy
 to
 say if either internals and community agrees with the proposed change
 and
 community people are making their opinion count.

 There are no plans (and enough people who'd veto such plans) to close
 the mailing list. Everybody might state their opinion and we are happy to
 receive (constructive) feedback and ideas here. And yes, this can be a bit
 painful due to different forms of trolling but leads to better results
respecting
 more opinions than a yes/no vote.

The problem with that model is that history has consistently shown that
those in power may listen, but will ultimately just do what they want,
anyway.


 johannes

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


I feel it's also worth reminding everyone that VCS accounts generally
aren't given away like candy.  Most people who have that access have done
something or another to earn it.

--Kris

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Mon, Sep 22, 2014 at 8:09 PM, Sanford Whiteman figureone...@gmail.com
wrote:

 Hi Kris,

 On a broad level, your RFC asserts that checkdnsrr() is used to
 determine whether or not a hostname exists, but you don't actually
 define exists.  It seems to me you're glossing over the fact that
 existence is application-specific and doesn't add up to one single
 RR type or set of types.

 For example, when setting up a web hosting account (www.example.com),
 or, say, an organization-wide account for a web app
 (sharepoint.example.com) when example.com's DNS is managed by the
 tenant, we may want to determine whether the hostname exists: Is
 there an A or CNAME RR in the DNS for that hostname?  [1] Of course,
 that A/CNAME needs to eventually point to your servers to be useful,
 but with this barebones, non-professional-grade check, we could at
 least tell the tenant they pre-created a record successfully. (Or,
 contrariwise, we could tell them the hostname already exists, so it
 may already be used by one of their other apps.) Note if checkdnsrr()
 did an ANY query, `true` would be meaningless in this context.  It
 would be an instant false-positive if there were only an SOA and a
 coupla NSs.

 But when setting up a new user for a different kind of app, we may use
 their e-mail address (j...@example.com) as their username and we'll
 most certainly use it for a verification e-mail.  Here, we might
 quick-check whether example.com exists in the mail context, giving a
 reasonable expectation that it will accept mail (maybe not ours, of
 course!): Is there an MX, A, or CNAME RR in the DNS for that
 hostname? [2] This is a different, perfectly valid way that a
 hostname may exist.  Note again if checkdnsrr() defaulted to ANY,
 `true` would be meaningless/misleading. And also note (I'll explore
 this again below) that an MX record is not required to accept mail.
 You can't decide that a domain is SMTP-nonexistent just because
 there's no MX.  Users will just be angry if they are already receiving
 mail and you tell them their address hard-failed your preflight check:
 warn them, perhaps, but leave it up to the SMTP layer to make those
 hard decisions.

 For another example, if you run a purpose-built DNS management app,
 you may want to know if a domain is in the DNS at all: Are there
 simply SOA and NS RRs in the DNS? This is another completely valid
 meaning.  You wouldn't want to check for CNAME, MX, or A here, since
 none of them are mandatory. True, you could in theory waste your
 resources on an ANY query for this one.  But it is not a compelling
 reason to have ANY be the default.

 For yet another example, if I'm building an SPF test tool I want to
 check if TXT or SPF/99 records exist for the hostname.  I don't care
 if the hostname has CNAME, MX, or A -- in fact, a hostname w/an SPF
 record solely to discourage Joe Jobs doesn't need to prove its
 existence in any other way.

 I mean, that's the thing about DNS. It serves tens of different
 purposes. It's not possible to assume what people are looking for when
 they build a specialized PHP app.  It could very well be that an app
 doesn't ever test for existence of A/CNAME, but only existence of SRV
 records. Or only PTRs.

 On one note I fully agree.  The defaulting to MX sucks.  But as others
 have pointed out it's a BC break to try to manipulate the arg list at
 this point in time.


I agree that it would be a BC, but I believe it would be a very minor one,
as I doubt very many people are relying on the current default behavior.
This minor level of BC would not be inappropriate for a major version
increment, as it's expected that there will be at least some BC there.

Based on your comments relating to DNS in general, it sounds like
defaulting to ANY wouldn't be much better than the current default.  I'm
beginning to lean heavily towards removing the second voting option and
limiting the scope of the RFC to just making the second argument required
for this reason.  What would happen is it'd throw an E_DEPRECATED for at
least the remainder of 5.x, then throw the usual E_WARNING for a missing
argument starting in 7.x with no default.

It has been my observation that a number of good ideas (and fixes to bad
ideas) have been set aside over fears of BC breakage.  While I agree
there's certainly a place for such caution, refusing to ever allow any BC
for such improvements even in major version increments essentially ties our
hands together and prevents the language from evolving past some of its
negative aspects.  BC is, by its very nature, a short-term concern.  I
doubt anybody is experiencing any problems caused by any BC that occurred
between PHP 3 and PHP 4, for example.  That's why I think major version
increments are the ideal time to implement more long-term objectives that
may carry a marginal short-term BC cost.  Given that just about everyone
here agrees that the current behavior is more or less ridiculous that
doesn't serve any use cases not better 

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Kris Craig]

On Mon, Sep 22, 2014 at 7:21 PM, Johannes Schlüter johan...@schlueters.de
wrote:

 Hi,

 On Mon, 2014-09-22 at 14:36 -0700, Kris Craig wrote:

   Slightly provocative:  Why should I be forced to maintain code by
  people who
   don't want to maintain it themselves?
 
  Nobody is forcing you to do anything.  You choose to contribute to PHP
  in the manner in which you do, just as other people choose to
  contribute in different, sometimes less obvious, ways.

 Right, nobody can truely enforce me doing something, still I gave some
 form of promise/commitment to less so since 5.3 reached EOL but still
 this might require me to do something.

  Probably even due to votes by people
   about whom I don't know anything? Mind that most maintenance work by
   most contributors happens in free time on a voluntarily base.
  
   And no open source doesn't mean democracy as governing model.
 
  It can.  Every project is governed differently.

 Well democracy can mean so many things - in ancient Greece, the origin
 of democracy, only the men of a social group had a vote. Even in
 Switzerland, which is famous for its direct democracy, women weren't
 allowed to vote till 1971 (in the canton Appenzell Innerrhoden even only
 till 1990 for municipal issues) in others the voting power is unequally
 distributed (see i.e. the EU parliament where larger countries have less
 MEPs than smaller ones and different voting system's in different
 countries give different weight to citizens of different countries)

 Anyways this is a way different debate.


Fair enough.



  Winston Churchill once famously said that democracy is the worst form
  of government, except all the others that have been tried.

 While this depends on your view on what is good - Louis XIV of France
 was quite happy with his, I assume. But government of a society is
 different from governance of a software project. One case leads to a
 revolution, the other to a fork.


Also fair enough.



  The
   democratic part is that people who don't like it can fork the
  project and
   eventually receive a higher traction.
 
  And then we can have dozens of competing PHP codebases floating
  around.

 That's were the social aspect comes back in - even people without a
 formal vote have ability to impact the project.


But that's assuming the threat of fork will be enough, thereby keeping
forks to a minimum.  I'm not sure I can concur with that assumption.



  The problem with that model is that history has consistently shown
  that those in power may listen, but will ultimately just do what they
  want, anyway.

 If those with power will ultimately just do what they want, anyway the
 official form of governance doesn't matter at all. Thanks for agreeing
 to that :-D


I think you misunderstood.  Ignoring vote results derived from a
legitimized process that was agreed to is much more difficult that ignoring
a request made by some person without karma, with or without the threat of
a fork.



 But as this went to a path through European history let me reiterate and
 clarify what I said in a different post in this thread: The strict
 dependence on a vote impacts the constructive feedback for proposers
 negatively. It also provides no feedbackloop for leading to constructive
 critic being ignored, it becomes less clear whether voters were aware of
 that. It also makes simple contributions hard, adding quite some
 transactional cost for small improvements by newcomers. (then again here
 is no clear and objective measure what small includes) This is
 demotivating for all sides.


I wouldn't be against modifying the voting process to require everyone to
state a brief reason for their vote in order for it to be counted.  The
current table could be modified to add a text column easily enough, I'm
sure, and the results could display the reason next to each vote in the
row.  I think that would at least help mitigate the concerns you're raising
here.



 The approach I have in mind is going back to a consensus model by
 default, allowing truly everybody to participate and giving the
 opportunity to call for a vote if consensus can't be reached. Given our
 social diversity I however think that this hardly works out as there
 always will be somebody calling for a vote ... obvious consequence would
 be a quorum for calling for a vote .. wich ends up in even more
 bureaucracy hell.


I've noticed that minor changes are already made all the time without a
vote being called and I don't have any problem with that, nor am I aware of
anyone else who does.  Perhaps we could clarify exactly when a vote is
required and when it's not, but since that does not appear to have been an
issue thus far, it would probably just be a solution in search of a problem.


 
  I feel it's also worth reminding everyone that VCS accounts generally
  aren't given away like candy.  Most people who have that access have
  done something or another to earn it.

 It depends on the time of day and position

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

I checked and it looks like E_WARNING is what we currently throw for that.
Should we consider changing that to E_ERROR?  I mean, if a function
*requires* an argument that's missing, I don't think we'd want that script
execution to continue.

What's the reasoning behind the current behavior of just throwing a warning
on broken function calls like this?  Are we just mimicking behavior in
other languages or something?  I'm sorry if this is a stupid question, but
I honestly can't figure out why it's preferable to only throw a warning on
these.

--Kris


On Fri, Sep 19, 2014 at 11:05 PM, Kris Craig kris.cr...@gmail.com wrote:


 On Sep 19, 2014 10:50 PM, Michael Wallner m...@php.net wrote:
 
 
  On 20 Sep 2014 04:15, Kris Craig kris.cr...@gmail.com wrote:
  
 
  
   From what I can tell, there are valid arguments to be made for both,
 so I
   would love to see some discussion/debate here regarding which solution
   should be implemented, as I'm currently undecided.  Also please feel
 free
   to point out any areas of improvement for the RFC itself.
  
 
  Functions don't throw E_ERROR on missing argument.
 
  And ANY is about as bad as MX.

 I can fix that.  What would be the customary one to throw for a missing
 arg?

 --Kris

Re: [PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

On Sep 19, 2014 10:50 PM, Michael Wallner m...@php.net wrote:


 On 20 Sep 2014 04:15, Kris Craig kris.cr...@gmail.com wrote:
 

 
  From what I can tell, there are valid arguments to be made for both, so
I
  would love to see some discussion/debate here regarding which solution
  should be implemented, as I'm currently undecided.  Also please feel
free
  to point out any areas of improvement for the RFC itself.
 

 Functions don't throw E_ERROR on missing argument.

 And ANY is about as bad as MX.

I can fix that.  What would be the customary one to throw for a missing arg?

--Kris

Re: [PHP-DEV] Why does checkdnsrr() default to MX??

[Kris Craig]

On Fri, Sep 19, 2014 at 10:24 AM, Adam Harvey ahar...@php.net wrote:

 On 19 September 2014 02:58, Chris Wright c...@daverandom.com wrote:
  On 18 September 2014 20:29, Kris Craig kris.cr...@gmail.com wrote:
  Hey guys,
 
  I just spent some time troubleshooting what appeared to be a DNS issue
  before I realized that, absent the optional $type argument, checkdnsrr()
  defaults to MX.  Can anybody explain why it's defaulting to MX and
 not
  ANY?  It seems really counter-intuitive.
 
  This is a big wtf, especially since getmxrr() exists. A cursory search
  of github (not the best measure I know, but easy) reveals only a few
  cases where this function is called without the second argument, and
  every case I've found looks like they were expecting an A record, so
  this code is likely broken anyway.
 
  In other words, +1 to change this to something saner ASAP.

 As an alternative, could we just make the type argument mandatory in
 PHP 7 and start issuing E_DEPRECATED warnings if it's omitted in 5.6
 or 5.7?

 Adam


I like both ideas.  Adam's approach would be more inconvenient for
developers, but it would also be less of a BC issue since merely changing
the default could cause some existing code to fail silently as opposed to
generating an error.  On the other hand, I can't think of any such use case
in which checking all DNS entries instead of just MX would cause any
scripts to break.  The only possible scenario I can think of would be if
they're using dnsrr() to check if an MX record exists and hit a host that
has an A record but not MX.  That would cause it to return TRUE when
they're expecting FALSE.

I'll draft an RFC when I get a chance and include both options in it.

--Kris

[PHP-DEV] [RFC] Change checkdnsrr() $type argument behavior

[Kris Craig]

Per discussion in an earlier thread.  Here's the RFC:

https://wiki.php.net/rfc/checkdnsrr-default-type


Basically, this RFC seeks to make it so that PHP's checkdnsrr() function,
which is most commonly used to see whether or not a hostname exists, no
longer restricts itself to only MX records by default.

Though the RFC itself is a no-brainer, the more difficult question is which
solution should be implemented.  The two options currently presented are
changing default from MX to ANY, which would cause it to check all
records and not just MX; and getting rid of the default altogether and
making it so that the argument is required.

From what I can tell, there are valid arguments to be made for both, so I
would love to see some discussion/debate here regarding which solution
should be implemented, as I'm currently undecided.  Also please feel free
to point out any areas of improvement for the RFC itself.

--Kris

Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?

[Kris Craig]

On Fri, Sep 19, 2014 at 7:25 PM, Kalle Sommer Nielsen ka...@php.net wrote:

 2014-09-20 3:29 GMT+02:00 Andrea Faulds a...@ajf.me:
  Hi!
 
  Perhaps I’m being unfair and overthinking things, but I wonder if it is
 really fair for people who have no karma, i.e. not contributors to the
 documentation, extensions, php-src or anything else, to have the ability to
 vote on RFCs?
 
  I’d never suggest people without internals karma can’t vote. I think doc
 and peck contributors are as valued as any other contributors. However,
 people with no karma whatsoever (a blank people.php.net page) voting irks
 me.
 
  Thoughts?

 I'm with you on this one, huge +1 for the separation on who can vote
 and changing the voting rfc.


 --
 regards,

 Kalle Sommer Nielsen
 ka...@php.net

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


The one problem with this is it doesn't take into account those who
contribute to PHP in other ways, such as administering tests, contributing
RFCs, etc.  I'm not necessarily against this, but if you want to garner
wide enough support, you might want to make the language a little more
inclusive.

Just my two cents.

--Kris

[PHP-DEV] Why does checkdnsrr() default to MX??

[Kris Craig]

Hey guys,

I just spent some time troubleshooting what appeared to be a DNS issue
before I realized that, absent the optional $type argument, checkdnsrr()
defaults to MX.  Can anybody explain why it's defaulting to MX and not
ANY?  It seems really counter-intuitive.

--Kris

Re: [PHP-DEV] Remove alternative PHP tags

[Kris Craig]

On Tue, Sep 9, 2014 at 6:32 PM, Andrea Faulds a...@ajf.me wrote:


 On 10 Sep 2014, at 01:21, Andrea Faulds a...@ajf.me wrote:

  Isn’t this a bit of a needless BC break? Not very nice on people with
 such codebases. It’s also worth pointing out that people might be using
 these to get around the XML ? issue (granted, you can disable short tags).
 
  I’d vote for this if you wrote a convertor script to help people
 migrate. Otherwise I think we’re just being unfair on people who used these
 tags.
 
  Actually, I’d like to see a Python 2to3-esque tool in general for PHP 7.
 The easier we make the migration, the more likely people will do it.

 Some further thoughts after discussing with Tyrael (Ferenc) on IRC.

 I initially thought that I’m not really against removing them really, but
 I think we should have a script to convert them first. Because someone,
 somewhere, is gonna need it.

 But then I’ve thought more about it. I’m usually OK with certain BC
 breaks, I just don’t like this specific one. It doesn’t affect me, but,
 well, I don’t see the point. It doesn’t really help language consistency or
 anything, (OK, sure, only two sets of delimeters now, but it’s not a big
 deal like some other things are), and you’ll force people to update every
 file in their codebase if they’re affected, assuming people who use
 alternative tags use them everywhere. There’s also a security issue here.
 If someone uses PHP 7 with a codebase that has these alternative tags, your
 code is now visible to users instead of the output, which might include
 configuration details like database passwords or password hash salts. It’s
 also possible that people won’t notice this is happening if they only used
 these alternative tags in a few obscure places.

 I wonder if, really, we might be better off keeping them around and just
 outputting E_DEPRECATED. If we do get rid of them in 7, we should have 5.7
 deprecate them.
 --
 Andrea Faulds
 http://ajf.me/





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


I think Andrea raises a valid point about BC.  I agree that those old tags
should go, but I'd suggest we target that removal for PHP 7 and just add a
deprecated flag on 5.x.

--Kris

Re: [PHP-DEV] [RFC] Better type names for int64 RFC

[Kris Craig]

On Aug 23, 2014 12:10 PM, Pierre Joye pierre@gmail.com wrote:

 On Sat, Aug 23, 2014 at 6:40 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
  On 8/22/14, 11:25 PM, Pierre Joye wrote:
  There is. Long is not used anymore. So we can argue about that but
  there is a change and it should be reflected imo.
 
  You still totally ignore any of my other points, which are even more
  important in regard to maintaining one code tree for 5.x and 7.x,
  which is very likely not possible in a sane way for many extensions.
 
  I ignored it because it is irrelevant.

 These points are not irrelevant:

 - zend_uint should go away, uint32_t should be used instead
 - zend_int_t could remain. it matches the respective, architecture
 specific int32_t
   and int64_t being used behind it. _t standing for _typed just like
 in the standard
   types intXX_t

 And we can add:

 - zend_size_t can be dropped in favor of size_t

 And dangerous APIs signature changes are not irrelevant either. And
 many of them are not related to performance at all but a choice made
 at the implementation time. So the solid technical reason you mention
 later does not apply here.

 On the same area, I would also prefer not to use STR_* defines but
 directly called zend_string_*, it will drastically reduce errors
 during porting or later.

  The fact that many related things
  are changing does not justify piling on more changes.

 RIght.

   Every change
  should have a very solid technical reason behind it. Long is not used
  anymore is not a solid technical reason.

 Consistent APIs, in my book, is a solid technical reason.

  The code will compile
  perfectly fine with it being IS_LONG. Also, these are userspace-facing
  in the sense that as an extension author we are dealing with PHP's type
  system consisting of lval, dval, string, array, object and resource. How
  exactly an lval or IS_LONG is implemented at the C level on any given
  platform is an implementation detail and could change, but we are still
  providing an lval to userspace.

 Extensions write should not use the zend_value member directly but use
 the provided APIs or macros, which is called Z_IVAL btw. Want to
 change to Z_LVAL? WIll be more consistent.

  As C developers, extension authors are
  more than capable of checking the actual macro definition if they want
  to know the details.

 I have not doubt about the capabilities of the extension developers,
 but improving APIs quality reduces the # of errors.

  I'd also appreciate if you would drop your toxicity level a few notches
  in your emails to the list, irc and twitter.

 I do not agree with your definition, but as long as there are double
 standards and related behaviors, I do not see how things can improve.
 The way this RFC has been handled is a shame. If NG would have got as
 much code reviews, got blocked twice while being accepted, etc. I do
 not think Dmitry or Laruence would be that happy at this point. And
 seriously, this is a pretty bad behavior. It is also not the 1st time
 it happens. Only difference is that I do not care much when something
 happens, I know each of you long enough, but other simply left.
 Anyway, it does not help anyone to argue about that over and over, I
 can agree with you on that.

 Cheers,
 --
 Pierre

 @pierrejoye | http://www.libgd.org

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


I have a quick question for the people debating this issue:  Aside from the
dispute over whether or not it's necessary / unimportant, are there any
pressing reasons *not* to implement the changes that Pierre is advocating?
I.e. would it break anything, waste a large amount of time, make the code
harder to maintain, etc?  Or is it just that you don't think it's worth
doing?

--Kris

Re: [PHP-DEV] On BC and not being evil (Was: Re: [PHP-DEV] [RFC] Integer Semantics)

[Kris Craig]

On Thu, Aug 21, 2014 at 8:30 AM, Derick Rethans der...@php.net wrote:

 On Tue, 19 Aug 2014, Kris Craig kris.cr...@gmail.com wrote:

  On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote:
 
   I have made an RFC which would make some small changes to how integers
   are handled, targeted at PHP 7:
  
   https://wiki.php.net/rfc/integer_semantics
  
   Thoughts and questions are appreciated. Thanks!
 
  snip
 
  And since you're targetting the next major release, BC isn't an issue.

 This sort of blanket statements that Backwards Compatibility is not an
 issue with a new major version is extremely unwarranted. *Extreme care*
 should be taken when deciding to break Backwards Compatibility. It
 should not be oh we have a major new version so we can break all the
 things™.

 There are two main types of breaking Backwards Compatibility:

 1. The obvious case where running things trough ``php -l`` instantly
tells you your code no longer works. Bugs like the two default cases,
fall in this category. I have no problem with this, as it's very easy
to spot the difference (In the case of allowing multiple default
cases, it's a fricking bug fix too).

 2. Subtle changes in how PHP behaves. There is large amount of those
things currently under discussion. There is the nearly undetectable
change of the Uniform Variable Syntax, that I already `wrote
about`_, the current discussion on `Binary String Comparison`_,
and now changing the `behaviour`_ on  and  in a subtle
way. These changes are *not okay*, because they are nearly
impossible to test for.

Changes that are so difficult to detect, mean that our users need to
re-audit and check their whole code base. It makes people not want to
upgrade to a newer version as there would be more overhead than
gains. Heck, even changing the ``$`` in front of variables to ``£``
is a better change, as it's *immediately* apparent that stuff
changed. And you can't get away with But Symfony and ZendFramework
don't use this either, as there is so much code out there

 As I said, the first type isn't much of a problem, as it's easy to find
 what causes such Backwards Compatibility break, but the second type is
 what causes our users an enormous amount of frustration. Which then
 results in a lot slower adoption rate—if they bother upgrading at all.
 Computer Science purity reasons to make things better have little to
 no meaning for PHP, as it's clearly not designed in the first place.

 Can I please urge people to not take Backwards Compatibility issues so
 lightly. Please think really careful when you suggest to break Backwards
 Compatibility, it should only be considered if there is a real and
 important reason to do so. Changing binary comparison is not one of
 those, changing behaviour for everybody regarding  and  is
 not one of those, and subtle changes to what syntax means is certainly
 not one of them.

 **Don't be Evil**


 cheers,
 Derick

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


Derick, I think you misunderstood my meaning.  It was never my intention to
imply that BC doesn't matter or that it should be taken lightly.  My
statement that it's not an issue was in the context of this RFC, which
people seem to overwhelmingly agree is a good idea.  When you have a
beneficial idea that people like, implemented in a major version increment,
BC is not an issue.  That's what I meant and I stand by that.

That said, I don't disagree with your larger points about BC being a
consideration even in major release increments.  However, I also feel the
need to point out that, historically, there have been a lot of known issues
in PHP that we've decided not to fix even in major increments because of
what I believe to be an excess of BC concern.  One example-- it's almost a
cliche at this point-- is the inconsistent function naming and argument
orders.  In my experience, that's been the most common complaint I hear
from PHP devs.  We've avoided cleaning that up because it would break all
kinds of stuff.  While I agree that BC should never be decided on lightly,
I do believe that an expectation exists that significant code updates will
have to be made by framework/etc maintainers when upgrading to a new major
release.  So I do think we should allow ourselves to finally correct these
lingering issues for the next major release.  It will slow adoption in the
short-term, but it is the right strategy for the language in the long-term.

TL;DR:  BC does matter and should never be taken lightly, but we should
also not be afraid to introduce some BC in a major release in order to
correct various longstanding issues.

--Kris

Re: [PHP-DEV] [RFC] Integer Semantics

[Kris Craig]

On Tue, Aug 19, 2014 at 3:36 PM, Andrea Faulds a...@ajf.me wrote:

 Good evening,

 I have made an RFC which would make some small changes to how integers are
 handled, targeted at PHP 7:

 https://wiki.php.net/rfc/integer_semantics

 Thoughts and questions are appreciated. Thanks!
 --
 Andrea Faulds
 http://ajf.me/





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


Makes sense to me.  I was a little uneasy at first, but you made a very
good point that a high-level language like PHP should be abstracting such
environment-dependent differences away.  And since you're targetting the
next major release, BC isn't an issue.

--Kris

Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single switch statement

[Kris Craig]

On Wed, Aug 13, 2014 at 3:21 PM, Drew Paroski drewparo...@gmail.com wrote:

 On 6 August 2014 12:32, Ferenc Kovacs tyr...@gmail.com wrote:
 
  I'm not sure what would be the best solution, but if we don't version the
  spec, then when we introduce BC breaks or simply new features in a new
  version which is in turn get's added to the spec, that would make the
 older
  php version's(from any implementation) not being compliant with the spec.

 I agree with Andrea that this fix/change is arguably not a BC break. For
 something where there is broad consensus that it's a bug (or at the very
 least
 highly undesirable behavior) and the fix has very low risk of breaking
 existing
 programs, it seems poor to update the spec to codify the bug. While the
 goal of
 the spec is to describe PHP 5.6's current behavior as it is, I think it
 should
 stop short of requiring that conforming implementations mimic existing
 bugs in
 php.net PHP 5.6.

 Making the spec codify bugs is bad for two reasons. First, it encourages
 other
 implementations to mimic bugs causing these bugs to propagate further and
 making them harder to ultimately fix. Second, it makes the spec more
 complicated and more difficult to maintain without delivering any real
 value.
 It's okay if php.net PHP is not 100% spec compliant as long as the all the
 differences are considered bugs.

 Going the RFC route for this issue felt a bit a like overkill to me, but I
 respect the process :). The spirited discussion here was interesting to
 read
 and informative. I don't have strong feelings about what version of
 php.net PHP
 the fix should be applied to, or whether it should be allowed but
 E_DEPRECATED
 for a period of time, but IMHO getting the fix in sooner rather than later
 feels like the right way to go.

 For future cases like this that are initially filed as bugs, I think
 discussion
 should first focus exhaustively on determining whether or not the issue is
 a
 bug before moving on to discussing whether the spec should be changed. I
 think
 this will help reduce churn on the spec and will keep things simpler and
 more
 light-weight for most cases like this.

 -Drew

 On Wed, Aug 13, 2014 at 9:22 AM, Matthew Fonda matthewfo...@gmail.com
 wrote:
  On Wed, Aug 13, 2014 at 3:24 AM, Peter Cowburn petercowb...@gmail.com
  wrote:
 
  My thoughts on the topic? I think we're in danger of letting process
 get
  in our way here. It's a bug fix which IMHO should even be thrown into
 5.6
   (this is a bug fix!). Going through the RFC process, being forced to
 wait
  for 5.7 or 7, extended discussions on the list... it all just seems
  unnecessary. But, that's just the opinion of a docs guy. :-)
 
 
  +1, my thoughts as well.
 
  Best regards,
  --Matt

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


I do feel it necessary to point out at this juncture that the last 16 hours
of this thread are EXACTLY why the RFC process requires a minimum of two
weeks of discussion before voting is initiated on language-touching
proposals.  I'll repeat my request that the author either cancel the
premature vote and wait the full two weeks or just cancel the RFC
altogether.  If you don't feel an RFC is necessary, that's fine.  But if
you do post an RFC, please follow the rules.

--Kris

Re: [PHP-DEV] [VOTE] Mutliple defaults in switch statements

[Kris Craig]

On Tue, Aug 12, 2014 at 10:08 AM, Andrea Faulds a...@ajf.me wrote:


 On 12 Aug 2014, at 17:53, Sara Golemon poll...@php.net wrote:

  Voting is open: https://wiki.php.net/rfc/switch.default.multiple#vote

 I’m all for this, but the *minimum* discussion period is *two* weeks.
 --
 Andrea Faulds
 http://ajf.me/





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


Agreed.  Please cancel the vote and re-open it after the required two weeks
has passed.

--Kris

Re: [PHP-DEV] [VOTE] Mutliple defaults in switch statements

[Kris Craig]

On Tue, Aug 12, 2014 at 2:36 PM, Sara Golemon poll...@php.net wrote:

 On Tue, Aug 12, 2014 at 10:08 AM, Andrea Faulds a...@ajf.me wrote:
  On 12 Aug 2014, at 17:53, Sara Golemon poll...@php.net wrote:
  Voting is open: https://wiki.php.net/rfc/switch.default.multiple#vote
 
  I’m all for this, but the *minimum* discussion period is *two* weeks.
 
 The two-week period is advisory


I don't believe that is correct.  Here's the actual wording:

There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is required.

The is required at the end suggests to me that this is more than merely a
suggestion.


 and we don't need to get hung up on
 process for the sake of process.


That's not what it is.  The minimum discussion period is there so that
everyone can take the time to evaluate a proposal *and* hear any dissenting
views that may emerge during this process before voting.  When something
gets fast-tracked like this, there could very well be someone with a
compelling argument against it who simply hasn't seen this RFC yet.  I
agree that's doubtful in this case, but the idea of just arbitrarily
deciding not to follow the rules sets a dangerous precedent, in my view.


 There's been no meaningful
 discussion in the past week because nobody thinks this is remotely a
 bad idea.


See above.


 Hell, some have questioned why this was put into an RFC in
 the first place. (It's arguably a bug, since the existing behavior
 could never have been described as right or intentional).

 If you're so worried about violating RFC process, I can revoke it
 entirely and just commit it without voting, and I'd be completely in
 the right.


I can't comment on that as it's well outside my purview.  What I can say is
that, if you're going to choose to use the RFC process as you did, then you
should follow that process and respect its guidelines.  I'd rather you
scrap the RFC entirely than set a precedent that people can just
arbitrarily decide that the rules don't apply to them.  I'm concerned about
the next person who posts an RFC and cites your actions as justification
for not following the posted guidelines.

Or, we can apply a reasonable amount of process without
 getting hung up on seven days worth of... no discussion whatsoever.


I think you're missing the point.  Please see my concerns above.



 -Sara

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

Re: [PHP-DEV] [VOTE][RFC] intdiv()

[Kris Craig]

On Thu, Jul 31, 2014 at 1:53 AM, Chris Wright c...@daverandom.com wrote:

 On 30 July 2014 18:51, Adam Harvey ahar...@php.net wrote:
  -1 explanation: I don't think %% is clear enough, the only sensible
  syntax choice (//) is unavailable to us, and I think the utility of
  having it baked into the language as an operator is pretty minimal
  regardless (I coded a lot of Python for scientific research in a
  previous job, and I don't think I ever used //, and you'd think that's
  the place where you'd use it).
 
  +1 on the function, though — quick searches on Ohloh and Github
  suggest that there are a grand total of three open source projects
  that implement a global intdiv() function. Seems safe enough.
 
  Adam
 

 This describes my voting choice exactly. I'm not against the idea of
 an operator, but %% is not the right operator choice for me. I could
 live with /% but it still doesn't feel quite right. I don't have a
 practical implementable suggestion for an alternative, so I guess
 we'll just have to live without it.

 Of course, this does not preclude us from introducing this in the
 future if someone comes up with a better idea :-)

 Thanks, Chris

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


Agreed.  I'd very much like to see another RFC that proposes more options
for creating an operator for this.  The vote against %% on this RFC should
not be construed-- in my opinion, at least-- as a consensus against having
any kind of operator for intdiv.

--Kris

Re: [PHP-DEV] [VOTE][RFC] intdiv()

[Kris Craig]

On Wed, Jul 30, 2014 at 11:01 AM, Peter Lind peter.e.l...@gmail.com wrote:

 On 30 July 2014 19:57, Sara Golemon poll...@php.net wrote:

  On Wed, Jul 30, 2014 at 10:54 AM, Andrea Faulds a...@ajf.me wrote:
   On 30 Jul 2014, at 18:51, Adam Harvey ahar...@php.net wrote:
   -1 explanation: I don't think %% is clear enough
  
   % returns the 2nd part of the integer division, %% returns the 1st.
  Surely that makes sense?
  
  That makes sense in PHP.  Probably only in PHP.
 
 
 Not even in PHP.


 --
 hype
 WWW: plphp.dk / plind.dk
 CV: careers.stackoverflow.com/peterlind
 LinkedIn: plind
 Twitter: kafe15
 /hype



This is why I still think we'd be better off using %/ or /%.

--Kris

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sat, Jul 26, 2014 at 11:10 PM, Michael Wallner mike.php@gmail.com
wrote:


 On 27 07 2014, at 02:53, Kris Craig kris.cr...@gmail.com wrote:
 
  So even IF you want to reduce the scope of the 2/3 requirement to
 language
  impacts in userland only, your RFC *still* falls under that requirement
  because it directly affects the language itself in userland, as described
  above.  I would again invite you to reconsider your position on this and
  avoid a protracted fight on this that would only serve to split the
  community.


 I’m actually not sure why we even have to vote on PHP-NG?

 How about for the crusaders to build something comparable to put up to
 vote against PHP-NG?

 There isn’t? Well, then let’s go ahead. Simple.


To answer your question (sort-of), the alternative to PHP-NG is what we
have right now.  I can't speak for anyone else, of course, but I certainly
am not opposed to PHP-NG, even though Zeev seems to think so.  I just don't
think it's ready to be merged into master yet, based on everything I've
seen, including concerns raised by others more knowledgeable than I on this
list.  I also just want to make sure something so massive in scope isn't
pushed through by a slim majority, especially since doing so would violate
the Voting RFC as it's currently written and would probably lead to an ugly
fight among those who have RW+ access.

I actually like PHP-NG and what it strives to do.  I just think its
developers are jumping the gun and trying to force something through that
many in the community feel is not yet ready for deployment.  I honestly
don't understand why there's such a rush and why people who are calling for
things to slow down so that cooler heads can prevail are being demonized
and mocked.  It's not you're either with us or you're against us.  I
don't oppose PHP-NG simply because I want to make sure all the ducks are in
a row before it's deployed.

Here's my question to counter yours, Michael:  What's the rush?

--Kris

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com
wrote:


 On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote:
 
  Here's my question to counter yours, Michael:  What's the rush?
 

 Every day php-ng is not GA, PHP is losing ground to its competitors.

Umm, how?  Do you have any data to support this?  According to
http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
 As far as our competitors are concerned, well:

http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python


As you can see, PHP continues to dominate with over 80% market share and no
signs-- at least, none that I can see-- that we are losing ground as you
stated.

So again:  What's the rush?

--Kris

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sun, Jul 27, 2014 at 1:03 AM, Michael Wallner mike.php@gmail.com
wrote:


 On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote:
 
 
 
 
  On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner 
 mike.php@gmail.com wrote:
 
 
  On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote:
  
   Here's my question to counter yours, Michael:  What's the rush?
  
 
  Every day php-ng is not GA, PHP is losing ground to its competitors.
 
  Umm, how?  Do you have any data to support this?  According to
 http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
  As far as our competitors are concerned, well:
 
 
 http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
 
 
  As you can see, PHP continues to dominate with over 80% market share and
 no signs-- at least, none that I can see-- that we are losing ground as
 you stated.
 

 Surely it's wise to make the same wrong assumptions Microsoft did with
 Internet Explorer?

Again, where's your evidence, Michael?  I provided two separate sources
that provide data showing that PHP is *gaining* market share and continues
to dominate over the competition, which directly contradicts the claim you
made.  Simply brushing this factual data as wrong assumptions-- without
any data of your own to back-up that claim-- does not constitute a valid
counter-argument, nor does introducing a non sequitur by comparing PHP to
Internet Explorer.

These aren't assumptions, wrong or otherwise.  This is data pulled from
reliable sources.  If you have separate data that calls it into question,
then please share it with us.  Otherwise, you're just making baseless and
factually inaccurate claims about PHP to justify your argument about
PHP-NG.  As far as I can tell from the evidence available, your statement
that PHP is losing ground to its competitors appears to be false.  In
fact, the exact opposite appears to be true.  Again, that's not an
assumption.  That's just looking at the available data.

--Kris

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sun, Jul 27, 2014 at 3:00 AM, Michael Wallner mike.php@gmail.com
wrote:


 On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com wrote:

 [a lot]

 Maybe because you see those as competitors,


You're the one who said PHP was losing ground to its competitors, not I.

but I see HHVM and friends as current competitors, being evaluated to
 replace stock PHP, which is definitely not covered by any nice statistics
 you can currently view.


So, in other words, you're basing your claim on anecdotal and purely
hypothetical assumptions about unnamed people evaluating other languages
to replace PHP.  Even if your self-serving guess were true, for which there
is no evidence that has been presented here, it still wouldn't substantiate
your claim because evaluating alternatives to your current codebase doesn't
mean you're going to actually switch to any of them.  So either way, PHP is
not, as you claimed, losing ground to anyone.

[a lot]


I've been trying to maintain a civil discussion here, but I have to say,
Michael, thus far you have done nothing but make immature, snyde personal
attacks and baseless, factually inaccurate claims.  You have not
contributed anything substantive or constructive to this debate up to this
point.  From your rolling eyes comment where you speculated about your
dog wanting voting rights to now, you have been very disrespectful and
uncivil toward everyone here.  I don't want to discourage anyone from
expressing their views, but on the same token, I'm not here to feed trolls.

This issue clearly brings out strong emotions in some people and we clearly
disagree on certain points.  That said, please make a greater effort to be
respectful toward other people on this list, whether you agree with them or
not.  Your trolling comments have all but hijacked this thread over the
last 17 hours and it's detracting from substantive debate that needs to
happen.

If you have some issue with me personally, please take it off-list.  If
you're going to post further on this thread, please try to be more
respectful and mature in your comments.

--Kris


http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 Hi all,

 On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner mike.php@gmail.com
 wrote:


 On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote:
 
 
 
 
  On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner 
 mike.php@gmail.com wrote:
 
 
  On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote:
  
   Here's my question to counter yours, Michael:  What's the rush?
  
 
  Every day php-ng is not GA, PHP is losing ground to its competitors.
 
  Umm, how?  Do you have any data to support this?  According to
 http://php.net/usage.php, as of 2012, PHP's usage is steadily
 increasing.  As far as our competitors are concerned, well:
 
 
 http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python
 
 
  As you can see, PHP continues to dominate with over 80% market share
 and no signs-- at least, none that I can see-- that we are losing ground
 as you stated.
 

 Surely it's wise to make the same wrong assumptions Microsoft did with
 Internet Explorer?

 PHP is losing as a general scripting language for sure.
 JavaScript is winning in this area even if it was originated as a web
 client scripting language.

 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
 http://langpop.com/

 We are better to consider this situation seriously. IMHO.
 Focus on web as well as encourage general usage is what we need.
 Making PHP a choice for new project should be one of the most important
 objective.

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net


According to w3techs, JavaScript retains an extremely tiny market share in
terms of general purpose languages:

http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js


It looks like the sources are all measuring different metrics.  It would be
interesting to see a closer analysis of the data and figure out which
metrics are the most relevant to this question.

--Kris

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski z...@zend.com wrote:




 On Fri, Jul 25, 2014 at 7:28 AM, Kris Craig kris.cr...@gmail.com wrote:



  While this is a major change to the language implementation, it does
 not actually affect end users in any meaningful way except for the positive
 ‘side effect’ of their apps running faster.  So while we believe that
 technically a 50%+1 vote should suffice, we hope to get well over 2/3.

 If you're not going to delay this, then you should at very least clarify
 the wording in this section.  You believe 50%+1 should suffice but hope to
 get well over 2/3.  So is the *required* majority 50%+1 or 2/3?


 The text I put there is exactly what I think about the subject of required
 majority.  50%+1 is enough for a change that does not effect end users in
 any meaningful way, but I'll be happier if it received a 2/3 majority to
 leave any doubts away.

 I should also point out that, according to the Voting RFC, whether or not
 an RFC actually affects end users in any meaningful way is NOT a factor
 in determining whether a 2/3 supermajority is required or not.  Here's what
 it actually states:

  For these reasons, a feature affecting the language itself (new syntax
 for example) will be considered as 'accepted' if it wins a 2/3 of the
 votes. Other RFCs require 50% + 1 votes to get 'accepted'.

 Since the phpng RFC already acknowledges that it affects the language
 itself, this is clearly a 2/3 requirement situation.  Whether it affects
 end-users or not is irrelevant.  Under current rules, your RFC must have
 2/3 support in order to pass.


 As the person who wrote that text in the Voting RFC, I can tell you with
 absolute certainty that you are 100% wrong in your interpretation, as I've
 said numerous times in the past.
 A feature that affects the *language* itself is not a feature that
 affects the *language implementation*.


That may be what you meant, Zeev, but that's not what you wrote.  As Jonny
already pointed out, what you intended isn't relevant if it doesn't match
the final wording you actually put in there.

The Voting RFC doesn't say language implementation.  It says language.
 That means, if it affects the language, it requires 2/3.  Period.  If you
wanted it to have a more narrow definition, then why didn't you put it in
there?  It's just not making any sense to me.  You might want to consider
putting an amendment to the Voting RFC to a vote to clarify that language,
but as it stands right now, any feature that affects the language itself--
regardless of userland impact-- requires a 2/3 vote.  Saying, Well, that's
not exactly what I meant, after the fact just isn't a convincing argument
for me.


 Generally speaking, now that we have a Specification project, the spirit
 of the Voting RFC is that changes to the Language Specification would
 require 2/3 majority, while all other changes would not.  This is also not
 100% accurate since there are some elements of the language behavior that
 aren't covered by the spec (e.g.superglobal availability and behavior) -


Again, I'd strongly suggest you propose new language for the Voting RFC to
reflect these statements, because none of that is apparent in the current
wording.


 but replacing the implementation with a compatible one absolutely does
 *not* fall within the realm of features that affect the language.


I disagree.  Whether or not the new stuff is compatible, it does directly
affect the language.  The PHPNG RFC itself even acknowledges that it
affects the language.  Furthermore, as far as the spirit of the Voting
RFC is concerned, I seriously doubt it would be in the spirit of it to
merge a massive overhaul of the codebase that will affect virtually all
development with just a simple majority.  It could be (and has been) argued
that this will inevitably lead to userland changes.  But again, whether it
affects userland or not is completely irrelevant.  The Voting RFC says--
whether you meant it to or not, it does say-- that 2/3 is required if it
affects the language, period.  It does not contain any exceptions for
lessened impact on userland.


 If you recall the 64-bit discussion several months ago, when I was (back
 then) on the opposing side, I clearly said to people who said this requires
 a 2/3 majority that it's very debatable - because while it does have some
 end user impact that changes the language behavior, it's mostly an
 implementation issue, which as such requires a simple majority.  So I'm
 both consistent, and not reinterpreting the rules to fit my needs.


Fair enough.  You have been consistent on this so I don't think anyone can
reasonably accuse you of just trying to twist this to suit your needs.



  As such, I ask that you at least update the wording to make it clear that
 2/3 *is* required for the RFC to pass in order to avoid confusion when it
 comes to a vote.  I still think you should hold-off until these other
 issues of dispute are resolved, though.  But that's your

Re: [PHP-DEV] RFC: Move phpng to master

[Kris Craig]

On Sat, Jul 26, 2014 at 3:16 PM, Zeev Suraski z...@zend.com wrote:

 Kris,



 I’ll make it short.



 EVERY RFC affects the language in *some* way – be it its features,
 positioning, perception, performance, implementation, testability, you name
 it.


I believe that argument is specious.  The RFC says, a feature
affecting the language *itself* (emphasis mine).  A feature that affects
performance need not necessarily affect the language itself.  For example,
an RFC to add an APXS configuration option to the configure script would
have no impact on the language itself, even though it technically involves
a modified implementation and testing scenario.  And affecting people's
perception of PHP most certainly does not constitute a feature that
affects the language itself, unless you're making a quantum theory argument
wherein the mere act of observing something alters its state.

Finally, here's an example from your RFC of how it *directly* impacts the
language itself:

 PHPNG doesn't keep original values of arguments passed to user functions,
so func_get_arg() and func_get_args() will return current value of argument
instead of the actually passed. The following code is going to be affected
“function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”

 Function parameters with duplicate name are not allowed anymore.
Definitions like “function foo($x,$x) {}” will lead to compile time error
“Redefinition of parameter”

So even IF you want to reduce the scope of the 2/3 requirement to language
impacts in userland only, your RFC *still* falls under that requirement
because it directly affects the language itself in userland, as described
above.  I would again invite you to reconsider your position on this and
avoid a protracted fight on this that would only serve to split the
community.

--Kris