Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 23:37, Rowan Tommins  wrote:
>
> On 20/08/2019 22:18, Peter Kokot wrote:
> >> The approach was: add the deprecation notice in PHP 8, and remove short 
> >> open tags in PHP 9 or PHP 10 (purposely left vague to get more support for 
> >> the idea - as getting the deprecation underway is the most important move).
> >>
> > I guess we should really highlight also
> > such option and discuss this more rationally back then. Now, we have
> > postponed this until who knows when and also without any clear
> > guideline for what will happen with short tags if they will be ever
> > removed or not...
>
>
> I honestly don't think it would make any difference to most people who
> voted against. The counter-arguments people have presented, again and
> again, are not about the pace of removal, but about whether removal is
> needed at all. If anyone wants to revive this proposal in future, it is
> that counter-argument that they would need to understand and address.
>
> Regards,

I think so too, yes. We will have the same discussion... I'll leave it
be. I just have my own opinion about them. Facts are facts (what
software does and allows to do) and what documentation and code
comments say (something completely different). What is programmer
advised to do is not the same as what can programmer do with the
language. That's all.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Tommins]

On 20/08/2019 22:18, Peter Kokot wrote:

The approach was: add the deprecation notice in PHP 8, and remove short open 
tags in PHP 9 or PHP 10 (purposely left vague to get more support for the idea 
- as getting the deprecation underway is the most important move).


I guess we should really highlight also
such option and discuss this more rationally back then. Now, we have
postponed this until who knows when and also without any clear
guideline for what will happen with short tags if they will be ever
removed or not...



I honestly don't think it would make any difference to most people who 
voted against. The counter-arguments people have presented, again and 
again, are not about the pace of removal, but about whether removal is 
needed at all. If anyone wants to revive this proposal in future, it is 
that counter-argument that they would need to understand and address.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 19:47, Peter Bowyer  wrote:
>
> On Tue, 20 Aug 2019 at 17:18, Peter Kokot  wrote:
>>
>> Let's simplify this a bit because I'm not sure I have seen anyone
>> mentioning something like a PHP 10 milestone in all these discussions.
>> If we want to get rid of some feature like this a very long timeline
>> needs to be done and also major versions needs to be taken into
>> consideration.
>
>
> It does indeed, and this approach was proposed by myself and another person.
>
> The approach was: add the deprecation notice in PHP 8, and remove short open 
> tags in PHP 9 or PHP 10 (purposely left vague to get more support for the 
> idea - as getting the deprecation underway is the most important move).
>
> It met with deafening silence.
>
> Peter

Then I apologize if your suggestion has been missed to do that like
this (there were too many emails stuck in loops and probably time
period of 5 to 10 years in the future is a bit problematic to
understand, and last but not least a bit of an issue when there is a
very clear feedback from people present since day 1 where they
recommend something else). I guess we should really highlight also
such option and discuss this more rationally back then. Now, we have
postponed this until who knows when and also without any clear
guideline for what will happen with short tags if they will be ever
removed or not...

--
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Sara Golemon]

On Tue, Aug 20, 2019 at 12:44 PM G. P. B.  wrote:

> > This has been a topic of discussion in the past. The agreement was that
> > non-author edits are permitted if they are isolated to a clear
> > "counter-arguments" section.  If someone had changed the meaning of the
> RFC
> > or of your arguments in favor of it that would be another story, but
> that's
> > not what happened here.
> >
>
> Gotcha so from now on I'll just add a sentence "George Peter Banyard
> supports this RFC" every time I'm in agreement with an RFC to the RFC
> because having your name tied to a vote is apparently irrelevant, because
> this is exactly what you did (but only on the RFC not the counter argument
> page).
>
> Gotcha. So you're not actually conversing in good faith. That's helpful to
know.

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Bowyer]

On Tue, 20 Aug 2019 at 17:18, Peter Kokot  wrote:

> Let's simplify this a bit because I'm not sure I have seen anyone
> mentioning something like a PHP 10 milestone in all these discussions.
> If we want to get rid of some feature like this a very long timeline
> needs to be done and also major versions needs to be taken into
> consideration.
>

It does indeed, and this approach was proposed by myself and another
person.

The approach was: add the deprecation notice in PHP 8, and remove short
open tags in PHP 9 or PHP 10 (purposely left vague to get more support for
the idea - as getting the deprecation underway is the most important move).

It met with deafening silence.

Peter

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[G. P. B.]

2019年8月20日(火) 16:47 Rowan Tommins :

> On 20/08/2019 13:51, G. P. B. wrote:
> >- I seriously don't appreciate that the RFC has been edited*WITHOUT*
> my
> > knowledge to add endorsement names on the counterargument to the RFC on
> the
> > RFC itself  when the appropriate place would have been the counter
> argument
> > document.
>
>
> While I appreciate that there is a certain implication of "ownership"
> when you are the author of an RFC, it is ultimately a resource for the
> community as a whole to understand the discussion, which is why the
> guide at https://wiki.php.net/rfc/howto explicitly mentions including
> both positive and negative feedback.
>
> The only problem I can see with other people editing "your" RFC is if
> later readers could mistake the edits for your own opinion; even if the
> whole counter-argument had been a section rather than a separate page,
> it would be clear that readers shouldn't do that. In this case, the only
> edits are to add a list of names, which is basically what the voting
> widget does anyway, so I really can't see any reason to be upset about it.
>
> Regards,
>
> --
> Rowan Tommins (né Collins)
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Citation:

> Note: An RFC is effectively “owned” by the person that created it. If you
> want to make changes, get permission from the creator.


Taken from: https://wiki.php.net/rfc

I'm upset that a voting document is edited without my knowledge, and I
don't see why I haven't been asked (probably because I would have said no
to the edits)


On Tue, 20 Aug 2019 at 17:18, Sara Golemon  wrote:

> This has been a topic of discussion in the past. The agreement was that
> non-author edits are permitted if they are isolated to a clear
> "counter-arguments" section.  If someone had changed the meaning of the RFC
> or of your arguments in favor of it that would be another story, but that's
> not what happened here.
>
> -Sara
>

Gotcha so from now on I'll just add a sentence "George Peter Banyard
supports this RFC" every time I'm in agreement with an RFC to the RFC
because having your name tied to a vote is apparently irrelevant, because
this is exactly what you did (but only on the RFC not the counter argument
page).


On Tue, 20 Aug 2019 at 18:02, Chase Peeler  wrote:

> > I think that now we need to fix the documentations out there. short
> > tags will stay in PHP for at least another 10+ years, so maybe we
> > should simply consider them not a part of legacy but a special kind of
> > a feature. There are some parts in PHP comments and docs that needs
> > this fixed and sorted out better a bit (probably - specially in the
> > ini files itself etc).
> >
> > I think we should still discourage their use. We should be explicit in
> the
> documentation that code which uses short tags might not be portable. Just
> because they exist, doesn't mean we should suddenly change our treatment of
> them when it comes to best practices. If there is any documentation that
> doesn't make this clear, submit a bug report.


The document has been discouraging their use for god knows how long.

> PHP also allows for short open tag * only available if enabled using the short_open_tag
>  php.ini
> configuration file directive, or if PHP was configured with the
> *--enable-short-tags* option).
>

See: https://www.php.net/manual/en/language.basic-syntax.phptags.php

On a final note, I don't think I have anything more to add to this topic so
I probably won't respond to subsequent messages in this thread.

Best regards

George Peter Banyard

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Tommins]

On 20/08/2019 17:56, Peter Kokot wrote:

Probably. But fact is that PHP opening short tags can be used. We can
enable them in controlled environments and use the short tags knowing
they will never be removed now. No deprecation warning is standing in
our way to do that now. And such code (or better put app) is honestly
now also not so bad. Because it will still work in at least let's say,
PHP 9 at least or considering the feedback and discussions for ever...
Also users who are already using short tags can now postpone the
upgrades for another ~5+ years at least :)



I don't think anything has changed in that regard. If there's text in 
the manual that short open tags are deprecated then it was wrong before 
this pair of RFCs; if there's text in the manual stating other reasons 
not to use them (portability, possibility of mixing in XML, etc) then it 
is still just as valid as it ever was.


If your impression was that the feature was already deprecated before 
the v1 RFC, and has somehow become *less* deprecated as a result of this 
vote, that may be explain some of the disconnect over the issue. As far 
as I'm aware, it had no such status, it was simply a feature that used 
to be more commonly used than it is today.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 18:39, Rowan Tommins  wrote:
>
> On 20/08/2019 17:18, Peter Kokot wrote:
> > About the docs - there are
> > very minor changes needed where "backwards compatibility" is mentioned
> > maybe. Because they are not in PHP for keeping BC anymore now. Nobody
> > proposed a better solution than this RFC, then they are a feature.
>
>
> Being "for Backwards Compatibility" and being "there forever" are not
> mutually exclusive. There are a huge number of things in this world
> which exist only to be compatible with an older technology or use case,
> but which will never be phased out, because the effort to change them
> exceeds the benefit.
>
> On the other hand, I think it might be useful to have a status of
> "officially discouraged" distinct from "deprecated". I occasionally hear
> people ask to "deprecate" something without any particular timeline or
> criteria for when it would be removed; my suspicion is that what they
> really want is a clearer message to users that they shouldn't use the
> feature.
>
> Regards,

Probably. But fact is that PHP opening short tags can be used. We can
enable them in controlled environments and use the short tags knowing
they will never be removed now. No deprecation warning is standing in
our way to do that now. And such code (or better put app) is honestly
now also not so bad. Because it will still work in at least let's say,
PHP 9 at least or considering the feedback and discussions for ever...
Also users who are already using short tags can now postpone the
upgrades for another ~5+ years at least :)

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Tommins]

On 20/08/2019 17:18, Peter Kokot wrote:

About the docs - there are
very minor changes needed where "backwards compatibility" is mentioned
maybe. Because they are not in PHP for keeping BC anymore now. Nobody
proposed a better solution than this RFC, then they are a feature.



Being "for Backwards Compatibility" and being "there forever" are not 
mutually exclusive. There are a huge number of things in this world 
which exist only to be compatible with an older technology or use case, 
but which will never be phased out, because the effort to change them 
exceeds the benefit.


On the other hand, I think it might be useful to have a status of 
"officially discouraged" distinct from "deprecated". I occasionally hear 
people ask to "deprecate" something without any particular timeline or 
criteria for when it would be removed; my suspicion is that what they 
really want is a clearer message to users that they shouldn't use the 
feature.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 18:02, Chase Peeler  wrote:
>
> On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot  wrote:
>
> > On Tue, 20 Aug 2019 at 14:51, G. P. B.  wrote:
> > >
> > > Hello internals,
> > >
> > > This RFC has been declined with 56% in favour (30/54) and 44% against
> > > (24/54).
> > >
> > > Two side notes to this:
> > >
> > >   - I seriously don't appreciate that the RFC has been edited *WITHOUT*
> > my
> > > knowledge to add endorsement names on the counterargument to the RFC on
> > the
> > > RFC itself  when the appropriate place would have been the counter
> > argument
> > > document.
> > >   - As it has no clear supra majority (nor against nor in favour), this
> > > topic should probably be put to discussion again in some way or form at a
> > > later stage.
> > >
> > > Best regards
> > >
> > > George P. Banyard
> >
> > The number of things that got wrong in these two RFCs is
> > extraordinary.
>
> What was done incorrectly in regards to the second RFC?
>
>
> > If anything the community, the internals and everyone
> > involved got through a good thinking process so we have learned
> > something from this in any way. I appreciate all your time and effort
> > to move this thing forward and even for being so respectful towards
> > Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
> > PHP and to repeat the voting with a better solution in this RFC.
> >
> > You say that like being respectful to people with opinion different than
> yours is something worth commending, when it should be the default
> behavior. In other words, you are implying that anyone that opposed this
> RFC didn't deserve respect, so, congratulations to everyone for showing it
> anyway.
>
>
> > I think that now we need to fix the documentations out there. short
> > tags will stay in PHP for at least another 10+ years, so maybe we
> > should simply consider them not a part of legacy but a special kind of
> > a feature. There are some parts in PHP comments and docs that needs
> > this fixed and sorted out better a bit (probably - specially in the
> > ini files itself etc).
> >
> > I think we should still discourage their use. We should be explicit in the
> documentation that code which uses short tags might not be portable. Just
> because they exist, doesn't mean we should suddenly change our treatment of
> them when it comes to best practices. If there is any documentation that
> doesn't make this clear, submit a bug report.
>
> If you really feel that we should start treating short tags as totally
> legitimate, then someone else with better knowledge of how to proceed with
> that will need to provide advice.
>

Let's simplify this a bit because I'm not sure I have seen anyone
mentioning something like a PHP 10 milestone in all these discussions.
If we want to get rid of some feature like this a very long timeline
needs to be done and also major versions needs to be taken into
consideration. And from all the discussions I got a feeling that not
everyone who voted "No" (who want the short tags in PHP) also want to
get rid of them. Ever. So that's why. We can live with short tags in
PHP as a feature. And so can legacy projects be upgraded to not use
them anymore so nothing to worry too much I think anymore now. We'll
discuss this maybe in 5 or 10 years then. About the docs - there are
very minor changes needed where "backwards compatibility" is mentioned
maybe. Because they are not in PHP for keeping BC anymore now. Nobody
proposed a better solution than this RFC, then they are a feature.
Cheers.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot  wrote:

> On Tue, 20 Aug 2019 at 14:51, G. P. B.  wrote:
> >
> > Hello internals,
> >
> > This RFC has been declined with 56% in favour (30/54) and 44% against
> > (24/54).
> >
> > Two side notes to this:
> >
> >   - I seriously don't appreciate that the RFC has been edited *WITHOUT*
> my
> > knowledge to add endorsement names on the counterargument to the RFC on
> the
> > RFC itself  when the appropriate place would have been the counter
> argument
> > document.
> >   - As it has no clear supra majority (nor against nor in favour), this
> > topic should probably be put to discussion again in some way or form at a
> > later stage.
> >
> > Best regards
> >
> > George P. Banyard
>
> The number of things that got wrong in these two RFCs is
> extraordinary.

What was done incorrectly in regards to the second RFC?


> If anything the community, the internals and everyone
> involved got through a good thinking process so we have learned
> something from this in any way. I appreciate all your time and effort
> to move this thing forward and even for being so respectful towards
> Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
> PHP and to repeat the voting with a better solution in this RFC.
>
> You say that like being respectful to people with opinion different than
yours is something worth commending, when it should be the default
behavior. In other words, you are implying that anyone that opposed this
RFC didn't deserve respect, so, congratulations to everyone for showing it
anyway.


> I think that now we need to fix the documentations out there. short
> tags will stay in PHP for at least another 10+ years, so maybe we
> should simply consider them not a part of legacy but a special kind of
> a feature. There are some parts in PHP comments and docs that needs
> this fixed and sorted out better a bit (probably - specially in the
> ini files itself etc).
>
> I think we should still discourage their use. We should be explicit in the
documentation that code which uses short tags might not be portable. Just
because they exist, doesn't mean we should suddenly change our treatment of
them when it comes to best practices. If there is any documentation that
doesn't make this clear, submit a bug report.

If you really feel that we should start treating short tags as totally
legitimate, then someone else with better knowledge of how to proceed with
that will need to provide advice.


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

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 14:51, G. P. B.  wrote:
>
> Hello internals,
>
> This RFC has been declined with 56% in favour (30/54) and 44% against
> (24/54).
>
> Two side notes to this:
>
>   - I seriously don't appreciate that the RFC has been edited *WITHOUT* my
> knowledge to add endorsement names on the counterargument to the RFC on the
> RFC itself  when the appropriate place would have been the counter argument
> document.
>   - As it has no clear supra majority (nor against nor in favour), this
> topic should probably be put to discussion again in some way or form at a
> later stage.
>
> Best regards
>
> George P. Banyard

The number of things that got wrong in these two RFCs is
extraordinary. If anything the community, the internals and everyone
involved got through a good thinking process so we have learned
something from this in any way. I appreciate all your time and effort
to move this thing forward and even for being so respectful towards
Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
PHP and to repeat the voting with a better solution in this RFC.

I think that now we need to fix the documentations out there. short
tags will stay in PHP for at least another 10+ years, so maybe we
should simply consider them not a part of legacy but a special kind of
a feature. There are some parts in PHP comments and docs that needs
this fixed and sorted out better a bit (probably - specially in the
ini files itself etc).

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Sara Golemon]

On Tue, Aug 20, 2019 at 7:51 AM G. P. B.  wrote:

>   - I seriously don't appreciate that the RFC has been edited *WITHOUT* my
> knowledge to add endorsement names on the counterargument to the RFC on the
> RFC itself  when the appropriate place would have been the counter argument
> document.
>
> This has been a topic of discussion in the past. The agreement was that
non-author edits are permitted if they are isolated to a clear
"counter-arguments" section.  If someone had changed the meaning of the RFC
or of your arguments in favor of it that would be another story, but that's
not what happened here.

-Sara

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Tommins]

On 20/08/2019 13:51, G. P. B. wrote:

   - I seriously don't appreciate that the RFC has been edited*WITHOUT*  my
knowledge to add endorsement names on the counterargument to the RFC on the
RFC itself  when the appropriate place would have been the counter argument
document.



While I appreciate that there is a certain implication of "ownership" 
when you are the author of an RFC, it is ultimately a resource for the 
community as a whole to understand the discussion, which is why the 
guide at https://wiki.php.net/rfc/howto explicitly mentions including 
both positive and negative feedback.


The only problem I can see with other people editing "your" RFC is if 
later readers could mistake the edits for your own opinion; even if the 
whole counter-argument had been a section rather than a separate page, 
it would be clear that readers shouldn't do that. In this case, the only 
edits are to add a list of names, which is basically what the voting 
widget does anyway, so I really can't see any reason to be upset about it.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[G. P. B.]

Hello internals,

This RFC has been declined with 56% in favour (30/54) and 44% against
(24/54).

Two side notes to this:

  - I seriously don't appreciate that the RFC has been edited *WITHOUT* my
knowledge to add endorsement names on the counterargument to the RFC on the
RFC itself  when the appropriate place would have been the counter argument
document.
  - As it has no clear supra majority (nor against nor in favour), this
topic should probably be put to discussion again in some way or form at a
later stage.

Best regards

George P. Banyard

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

[Robert Korulczyk]

> 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

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> This does not explain how someone could use that feature *by accident*. I gave
> an example where you can use short open tags by accident, and it is really 
> easy
> (the most popular IDE sometimes generates code with short open tags) and hard
> to notice (it is not easy to spot a difference between ` can
> you compare this to situation when you create a separate file with an explicit
> directive to disable PHP engine, and then be surprised that code is not 
> executed?

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"?

If a coder (or IDE) has written 'http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> I did mention such example with the 'engine' setting ( 
> https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's 
> PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik 
> it's sapi specific) but technically it can happen just in one "hard to 
> notice" subdirectory/tree.

This does not explain how someone could use that feature *by accident*. I gave 
an example where you can use short open tags by accident, and it is
really easy (the most popular IDE sometimes generates code with short open 
tags) and hard to notice (it is not easy to spot a difference between `http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> -Original Message-
> From: Robert Korulczyk [mailto:rob...@korulczyk.pl]
>
>
> Can you give an example where using `.user.ini` may create unexpected and hard
> to notice code leaks?

I did mention such example with the 'engine' setting ( 
https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's 
PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik it's 
sapi specific) but technically it can happen just in one "hard to notice" 
subdirectory/tree.

Note that atm short_tags are by default enabled and the disable happens only in 
php(-cli).ini so unless one throws the ini configuration files around willy 
nilly it is a deliberate decision from administrator. 



p.s. to clarify I'm not against changing the default value to disabled (to be 
consistent with the distributed ini-examples and (coding) recommendations) but 
I still don't understand what is the reason to deny for end-users the ability 
to change/re-enable this feature if they need it and choose so.

But according to some emails for some reasons the existence of short tags now 
has turned out to be a major language future/feature blocker .. so go figure.

rr


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> Argument for "only a particular code path in a particular environment" is 
> somewhat weak because in that case  why does even ' .user.ini' feature exists 
> (especially in apache sapi where you can even do engine = 0) as it also can 
> lead to wildly different language behaviour?

Can you give an example where using `.user.ini` may create unexpected and hard 
to notice code leaks?


Regards,
Robert Korulczyk

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

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> -Original Message-
> From: Bishop Bettini [mailto:bis...@php.net]
>
> That's why I highlighted Robert Korulczyk's case study: only a particular 
> code path in a particular environment had the problem.
>
> The status quo enables deployments to fail insecurely.  "secret"; is a trap waiting to spring. I would rather require ten thousand
> people secure their environment by running a script, than risk a single person
> exposing their credentials for all to steal.
> 
> I challenge everyone who's voted no to consider this balance.


If the initial RFC would have been accepted as is (without the later proposed 
changes after the lengthy discussion) you would have sprung the same "trap" as 
in that particular case study -  code would be exposed.


Argument for "only a particular code path in a particular environment" is 
somewhat weak because in that case  why does even ' .user.ini' feature exists 
(especially in apache sapi where you can even do engine = 0) as it also can 
lead to wildly different language behaviour?

rr


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Bishop Bettini]

On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski  wrote:

> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini  wrote:
>
>> On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:
>>
>> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
>> > It is expected to last two (2) weeks until 2019-08-20.
>> >
>> > A counter argument to this RFC is available at
>> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>> >
>
> If anyone needs to justify the effort, let them say "> hole".
>>
>
> It's a security hole in the exact same level that httpd.conf is a security
> hole.  Yes, misconfiguring your Web server can have severe consequences.
> Thankfully, it's not nearly that big of a Thing for us to be concerned
> about.
>

No, not even close to the same level.

If my web server's misconfigured, (ALL) of my code's exposed. It's trivial
to write a test to prove that my web server is properly serving PHP files.

But if PHP's misconfigured, (all OR some OR none) of my code's exposed. The
only way to decide is to literally check everything. That's why I
highlighted Robert Korulczyk's case study: only a particular code path in a
particular environment had the problem.

The status quo enables deployments to fail insecurely. 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Thu, Aug 8, 2019 at 3:35 PM Zeev Suraski  wrote:

> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini  wrote:
>
> > On Tue, Aug 6, 2019 at 7:34 AM G. P. B. 
> wrote:
> >
> > > The voting for the "Deprecate short open tags, again" [1] RFC has
> begun.
> > > It is expected to last two (2) weeks until 2019-08-20.
> > >
> > > A counter argument to this RFC is available at
> > > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> > >
> > > Best regards
> > >
> > > George P. Banyard
> > >
> > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
> >
> >  2007
> > when Facebook's source code leaked precisely because of this [1]?
> >
>
> Where's the evidence that it was precisely or even remotely because of
> this?  Literally all of the PHP code leaks I've come across over the years
> had to do with a misconfigured Web server - e.g., load Apache without
> properly setting up handling for .php files, or having things like .inc
> files not blocked from HTTP access.
> As we deprecate short_tags, should we consider deprecating all SAPIs, and
> roll our own high-performance Web server into PHP?  That's the only way to
> truly do away with the main vector for PHP source code leakage.
>
>
> >
> > Much has been said about this being a "portability" issue. I think that's
> > overly specific. The core issue is "fallibility". You can globally
> > configure the language to stop recognizing itself as a language. That's
> > weird and unexpected. So much so, that no one gives due thought to this,
> > and we end up with security disasters.
> >
>
> Except these are so uncommon and rare (I'm not aware of a single one, which
> doesn't mean there weren't any - but that they're not very common at all),
> that perhaps, just perhaps, it's a bit of an exaggeration to present them
> as a clear and present danger.
>
> PHP.net has opined, for years, that 
>
> This is the opinion of the person who wrote this document.  I'm sure many
> agree with him - but there's no person named 'PHP.net' that can opine on
> things.
> That said - if you think people read the manual and are aware that this is
> discouraged and act accordingly - it's all the more reason to not care
> about this issue.  If they don't, well, then it doesn't mean much that it's
> written over there.  I personally don't think too many people read the
> manual on PHP's opening tags (I have absolutely no data to back this gut
> feeling up - it's just my gut feel).
>
>
> > It's time to act. So much
> > else breaks at the 8.0 boundary, let's do it all at once.
>
>
> The "we're breaking things so badly anyway, let's break'm some more"
> argument has been refuted many times on this list.  First, I don't think
> we're breaking anything really badly in PHP 8.  And secondly, this remains
> as bad a reason as it's ever been to break stuff.
>
> Breakage is not binary - it accumulates.  The more you have of it - the
> more difficult it is to migrate, and the slower is the migration.
>
>
> > If anyone needs
> > to justify the effort, let them say " >
>
> It's a security hole in the exact same level that httpd.conf is a security
> hole.  Yes, misconfiguring your Web server can have severe consequences.
> Thankfully, it's not nearly that big of a Thing for us to be concerned
> about.
>
> We need to get rid of the display_errors ini directive as well. It
definitely shouldn't default to "1" or be set to "1" in the sample files
distributed with PHP. I would think this is a much greater security risk
than short tags. While we're at it, we need to get rid of the ability to
even set custom error handlers. If a programmer doesn't use that correctly,
they could still end up exposing error messages that contain sensitive
data.


> Zeev
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Zeev Suraski]

On Thu, Aug 8, 2019 at 10:35 PM Zeev Suraski  wrote:

>
>
> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini  wrote:
>
>> On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:
>>
>> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
>> > It is expected to last two (2) weeks until 2019-08-20.
>> >
>> > A counter argument to this RFC is available at
>> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>> >
>> > Best regards
>> >
>> > George P. Banyard
>> >
>> > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>>
>> > when Facebook's source code leaked precisely because of this [1]?
>>
>
> Where's the evidence that it was precisely or even remotely because of
> this?
>

I'd like to add that looking at the source code[1] from the leaks, it
appears to be using long tags - which means that if it is authentic - short
tags were not the source of the leak.
Also, there was a Perl leak[2] from Facebook as well.  It's a bit difficult
to blame short tags for that one.

Zeev

[1] https://gist.github.com/nikcub/3833406
[2] https://gist.github.com/philfreo/7257723

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Zeev Suraski]

On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini  wrote:

> On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:
>
> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> > It is expected to last two (2) weeks until 2019-08-20.
> >
> > A counter argument to this RFC is available at
> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> >
> > Best regards
> >
> > George P. Banyard
> >
> > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>
>  when Facebook's source code leaked precisely because of this [1]?
>

Where's the evidence that it was precisely or even remotely because of
this?  Literally all of the PHP code leaks I've come across over the years
had to do with a misconfigured Web server - e.g., load Apache without
properly setting up handling for .php files, or having things like .inc
files not blocked from HTTP access.
As we deprecate short_tags, should we consider deprecating all SAPIs, and
roll our own high-performance Web server into PHP?  That's the only way to
truly do away with the main vector for PHP source code leakage.


>
> Much has been said about this being a "portability" issue. I think that's
> overly specific. The core issue is "fallibility". You can globally
> configure the language to stop recognizing itself as a language. That's
> weird and unexpected. So much so, that no one gives due thought to this,
> and we end up with security disasters.
>

Except these are so uncommon and rare (I'm not aware of a single one, which
doesn't mean there weren't any - but that they're not very common at all),
that perhaps, just perhaps, it's a bit of an exaggeration to present them
as a clear and present danger.

PHP.net has opined, for years, that  It's time to act. So much
> else breaks at the 8.0 boundary, let's do it all at once.


The "we're breaking things so badly anyway, let's break'm some more"
argument has been refuted many times on this list.  First, I don't think
we're breaking anything really badly in PHP 8.  And secondly, this remains
as bad a reason as it's ever been to break stuff.

Breakage is not binary - it accumulates.  The more you have of it - the
more difficult it is to migrate, and the slower is the migration.


> If anyone needs
> to justify the effort, let them say "

It's a security hole in the exact same level that httpd.conf is a security
hole.  Yes, misconfiguring your Web server can have severe consequences.
Thankfully, it's not nearly that big of a Thing for us to be concerned
about.

Zeev

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Bishop Bettini]

On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:

> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> It is expected to last two (2) weeks until 2019-08-20.
>
> A counter argument to this RFC is available at
> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>
> Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2


I voted "yes" for removal. https://techcrunch.com/2007/08/11/facebook-source-code-leaked/
[2]:https://www.php.net/manual/en/language.basic-syntax.phptags.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> I'd say this is not really a language concern and more tooling and testing 
> problem. It's a class of a genuine mistake everybody does from time to time
> - be it wrong PHP tag, HTML tag or closing } added on the wrong line 
> resulting in a logical error.

This is a direct consequence of the language having settings that cause the 
same code to be interpreted (and works perfectly fine) in one environment
and be displayed in other (without any warning). This is not the same as a typo 
in HTML tag or logical error in code. This is literally a tool for
shooting yourself in the foot - it exists, but no one should use it.

And it is still really easy to use it by accident. For example, this is what 
PhpStorm generates when you try to inline-comment tag with short echo:




Regards,
Robert Korulczyk

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 17:42, Chase Peeler :

>
>
> On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks 
> wrote:
>
>> чт, 8 авг. 2019 г. в 16:42, Peter Kokot :
>>
>>> Hello,
>>> Thanks for sharing your stories about issues. Maybe we should start
>>> also thinking about the impact on the language attractiveness to pick
>>> it when starting a new web project since the core people can't come to
>>> conclusions how to make the language more consistent on the long run
>>> (PHP 9 etc)... With more and more ambiguities, inconsistencies,
>>> lockups, and dead ends behind the language there is probably also a
>>> bit of a factor to consider that it lowers this attractiveness.
>>> Meaning less people will think of adopting it (with all the things
>>> combined - short tags, that and that inconsistency not being removed
>>> from PHP due to major disastrous BC break there and there). So, the
>>> damage is also on the long run with more and more locks and dead ends
>>> not being able to be fixed and cleaned.
>>>
>>>
>>> --
>>> Peter Kokot
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>> Hello.
>>
>> Peter above put my thoughts perfectly.
>>
>> BC is great, but you need to pull the cord at some point. And the whole
>> short tag back and forth, with deprecation warning and stuff, has been
>> around for last half a decade. It is time to accept that it needs to go and
>> there should be no runtime dependent switch for this. Valid PHP tags are
>> `> I really liked how language picked up the cleanup pace in the last few
>> years and it needs it. I finally see genuine interest in people to actually
>> either come back or pick it up instead of JavaScript (NodeJS) and other
>> fancy new shiny stuff. And a lot of it is because of the cleanup efforts
>> and WTF?! removal, the language having the option to be stricter (I was not
>> a fan of strict mode when it was coming up - now I don't use anything else
>> - it is AWESOME).
>> If the old guard starts to push back as much as I have seen here, we are
>> going to lose momentum as a community and have people not willing to work
>> on PHP as much. I mean anyone who has been on this list for more than 10
>> years should remember how it was in 5.0-5.4 days - slow, painful and
>> somewhat unfriendly, until a few major contributors kind'a muddled though
>> and pushed a few major changes that allowed the momentum to build up and
>> somewhat break the stalemate (and it did help that HHVM reared it's head
>> and had stroked a few egos the wrong way). I guess the curve repeats
>> itself, but we should make an effort to curb it and not revert back to "BC,
>> BC, BC" holding everything up.
>>
>> Wait, how could positive progress have been made while short tags still
> existed?
>
>
>> Reality is, a lot of those "non-tech company" examples people give here
>> has nothing to do with language evolution. Yes, they are users, but we are
>> not responsible for the code they write, for the way they configure their
>> web servers and the way they can run a PHP4 server past 10 years and still
>> have no clue, because nobody cares or "it works, it makes money, no need to
>> invest". I would say that most of us on this list, if not everyone, are
>> smart enough to run/leave/not work for companies like that, so we are
>> somewhat shielded from that ignorance and just forget how bad it can be.
>>
>> Long story short - indecision is not an option. The previous RFC has
>> passed. Everyone involved, I hope, understands that yes, there will be
>> stuff going wrong for some users who are careless and/or ignorant and live
>> under a rock. Can we really do anything about that? I would say no unless
>> we freeze the language and do nothing. I mean I have exposed my PHP code
>> during server setup by just forgetting to do `systemctl reload nginx`,
>> hitting the URL and getting my `index.php` on the screen more times than I
>> care to confess to.
>>
> You're in the "all or nothing" logical fallacy. You are acting as if being
> against the removal of short tags is the same as being against any BC break
> at all. As we've said MANY times, BC breaks aren't the issue. THIS
> PARTICULAR BC BREAK IS THE ISSUE. It provides little to no positives to the
> users and does very little, if anything, to improve the language. At the
> same time it WILL lead to a very big barrier in terms of the ability to
> upgrade for a large number of users.
>

The RFC's both covered the fact that there is no good way to deprecate and
remove short tags cleanly. Whatever road you take - it is going to result
in issues for some users.
The crux here is not the tags themselves per-se, but the engine level
switch that changes the functionality of how the code is parsed. I mean if
push comes to shove and people really really really do not want to remove
`
>
>> Let's look into the future, use a reasonable amount of caution and/or
>> deprecation notice periods, but 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 17:56, Robert Korulczyk :

> > Many people have talked about the potential impacts of keeping short
> tags.
> > I have yet to see anyone give an actual example where they have been
> > negatively impacted by their existence. I've given you my personal story
> of
> > how removing them will negatively impact my company. I welcome anyone
> that
> > can provide an actual incident where the existence of short tags hurt
> them,
> > or, the continued existence is likely to have a large negative impact on
> > them in the future.
>
> I was bitten by short open tags. Despite the "no short open tag" policy in
> our app, one occurrence of ` email template so it was quite hard to notice on production. Especially
> that short open tags were disabled only on CLI, so we had code leak only in
> emails sent by cron. It took over a month to notice that bug.
>
> You may be concerned about people abandoning PHP due to BC breaks, I'm
> more concerned about people abandoning PHP because of issues like this. It
> gives me the impression that the language wants to hurt you...
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'd say this is not really a language concern and more tooling and testing
problem. It's a class of a genuine mistake everybody does from time to time
- be it wrong PHP tag, HTML tag or closing } added on the wrong line
resulting in a logical error.
-- 
Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 17:57, Peter Bowyer :

>
>
> On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks 
> wrote:
>
>> I really liked how language picked up the cleanup pace in the last few
>> years and it needs it. I finally see genuine interest in people to
>> actually
>> either come back or pick it up instead of JavaScript (NodeJS) and other
>> fancy new shiny stuff. And a lot of it is because of the cleanup efforts
>> and WTF?! removal, the language having the option to be stricter
>>
>
> Are you sure assigning this interest to cleanup efforts is not a
> correlation without causation?
>
> Other reasons interest in PHP can be growing:
> 1. We've got better libraries, frameworks and tooling in userland PHP than
> we used to have.
> 2. The hype cycle is wearing off NodeJS
> 3. people are slowly letting go of their outdated memories of what writing
> PHP / PHP code written by inexperienced programmers was like
>
> Peter
>

Everything is a contributor obviously, but in my personal experience the
one that really makes waves is when I tell people about "strict_types" and
"type hints". That really shocks people and make them look at 7.1+ with a
completely different attitude.

I mean I'm not claiming this is statistically sound data of a wide slice of
PHP users, but I do know quite a lot of somewhat closeted PHP developers
who do not show any public activity and just silently consume PHP and I'm
reluctantly playing the role of news gateway on what's new in PHP world. I
encouraged a few for years to move to better companies cause they were
stuck in a dead-end and just did not knew what is out there. No amount of
keeping the BC would make migrations to new versions in those environments
an easy task - stuff always broke, always in production, because devs had
no say or sometimes even did not know they are upgrading after the fact.

This is why I do not like excessive keeping of BC - there will always going
to be users like that, even major users, whom you do not suspect, but it is
a cl***k behind the scenes and that user can do 9-10 digit turnover a year.
Proper announcements, proper depreciation period, documentation update and
strong upgrade node message should cover everyone who is ready to listen
and understand. There are multiple tools to do short tag to long tar
conversion in bulk. I thought it was agreed years ago that runtime switches
that affect engine behaviour in a major way were bad and should be
eventually removed. And portable code version is using `https://t.me/psihius

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> Many people have talked about the potential impacts of keeping short tags.
> I have yet to see anyone give an actual example where they have been
> negatively impacted by their existence. I've given you my personal story of
> how removing them will negatively impact my company. I welcome anyone that
> can provide an actual incident where the existence of short tags hurt them,
> or, the continued existence is likely to have a large negative impact on
> them in the future.

I was bitten by short open tags. Despite the "no short open tag" policy in our 
app, one occurrence of `http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Thomas Hruska]

On 8/8/2019 3:26 AM, Côme Chilliet wrote:

Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :

Pretty much everyone (if not actually
everyone) that is against this RFC has stated that they don't actually use
short tags, and do not advocate that anyone else use them either.


This is what bugs me, the counter argument page from Zeev states «I never use 
short tags in any PHP code that I write, and as far as I recall - I never have. 
»,
  and at the same time «put hundreds of thousands of people through additional 
pain when upgrading.»

Is there any data that support the theory that hundreds of thousands of people 
use short tags?

Did anyone in this discussion stated that he was using them?



I used to use them extensively right up until the first RFC passed (e.g. 
CLI scripts, personal web apps, and some production systems).  Had 
several thousand references to resolve but I'm off them now, whichever 
way this second RFC round goes.  Other people chimed in that they use 
them too in "legacy production systems."


Open source userland development demands the long open tag.  So any 
scans of open source, public repos is going to be skewed heavily against 
actual use of short open tags.  You simply can't rely on Composer or 
GitHub stats to show real-world usage numbers in this instance.


So, yeah, people use them.

Also, just because a lawyer, a lobbyist, or an ambassador are themselves 
unaffected by some issue doesn't mean they can't represent a class of an 
underserved population to bring forth awareness, justice, or action.  In 
many cases, they are in better positions with sufficient contacts to 
reach the right people to bring forth such things that would otherwise 
never come to light.


--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Thu, Aug 8, 2019 at 11:18 AM Arvids Godjuks 
wrote:

> чт, 8 авг. 2019 г. в 16:42, Peter Kokot :
>
>> Hello,
>> Thanks for sharing your stories about issues. Maybe we should start
>> also thinking about the impact on the language attractiveness to pick
>> it when starting a new web project since the core people can't come to
>> conclusions how to make the language more consistent on the long run
>> (PHP 9 etc)... With more and more ambiguities, inconsistencies,
>> lockups, and dead ends behind the language there is probably also a
>> bit of a factor to consider that it lowers this attractiveness.
>> Meaning less people will think of adopting it (with all the things
>> combined - short tags, that and that inconsistency not being removed
>> from PHP due to major disastrous BC break there and there). So, the
>> damage is also on the long run with more and more locks and dead ends
>> not being able to be fixed and cleaned.
>>
>>
>> --
>> Peter Kokot
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Hello.
>
> Peter above put my thoughts perfectly.
>
> BC is great, but you need to pull the cord at some point. And the whole
> short tag back and forth, with deprecation warning and stuff, has been
> around for last half a decade. It is time to accept that it needs to go and
> there should be no runtime dependent switch for this. Valid PHP tags are
> ` I really liked how language picked up the cleanup pace in the last few
> years and it needs it. I finally see genuine interest in people to actually
> either come back or pick it up instead of JavaScript (NodeJS) and other
> fancy new shiny stuff. And a lot of it is because of the cleanup efforts
> and WTF?! removal, the language having the option to be stricter (I was not
> a fan of strict mode when it was coming up - now I don't use anything else
> - it is AWESOME).
> If the old guard starts to push back as much as I have seen here, we are
> going to lose momentum as a community and have people not willing to work
> on PHP as much. I mean anyone who has been on this list for more than 10
> years should remember how it was in 5.0-5.4 days - slow, painful and
> somewhat unfriendly, until a few major contributors kind'a muddled though
> and pushed a few major changes that allowed the momentum to build up and
> somewhat break the stalemate (and it did help that HHVM reared it's head
> and had stroked a few egos the wrong way). I guess the curve repeats
> itself, but we should make an effort to curb it and not revert back to "BC,
> BC, BC" holding everything up.
>
> Wait, how could positive progress have been made while short tags still
existed?


> Reality is, a lot of those "non-tech company" examples people give here
> has nothing to do with language evolution. Yes, they are users, but we are
> not responsible for the code they write, for the way they configure their
> web servers and the way they can run a PHP4 server past 10 years and still
> have no clue, because nobody cares or "it works, it makes money, no need to
> invest". I would say that most of us on this list, if not everyone, are
> smart enough to run/leave/not work for companies like that, so we are
> somewhat shielded from that ignorance and just forget how bad it can be.
>
> Long story short - indecision is not an option. The previous RFC has
> passed. Everyone involved, I hope, understands that yes, there will be
> stuff going wrong for some users who are careless and/or ignorant and live
> under a rock. Can we really do anything about that? I would say no unless
> we freeze the language and do nothing. I mean I have exposed my PHP code
> during server setup by just forgetting to do `systemctl reload nginx`,
> hitting the URL and getting my `index.php` on the screen more times than I
> care to confess to.
>
You're in the "all or nothing" logical fallacy. You are acting as if being
against the removal of short tags is the same as being against any BC break
at all. As we've said MANY times, BC breaks aren't the issue. THIS
PARTICULAR BC BREAK IS THE ISSUE. It provides little to no positives to the
users and does very little, if anything, to improve the language. At the
same time it WILL lead to a very big barrier in terms of the ability to
upgrade for a large number of users.



> Let's look into the future, use a reasonable amount of caution and/or
> deprecation notice periods, but please stop trying to block features
> "because stupid users". You give them the most secure software you can
> write, they go change settings on their own and get p0wned/defaced/hacked
> anyway even when you tell them not to do it and that y'r refusing to work
> on their project because of decisions they make.
>
> Actually, most BC breaks, including this one, seem to be focused on
preventing issues from "stupid users." We're saying that short tags are bad
because of reasons. We can't trust users to not use short tags as long as
they exist, 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Collins]

On Thu, 8 Aug 2019 at 16:18, Arvids Godjuks 
wrote:

> BC is great, but you need to pull the cord at some point. And the whole
> short tag back and forth, with deprecation warning and stuff, has been
> around for last half a decade. It is time to accept that it needs to go
>


That's like saying from now on we should mandate PSR-2 indenting style in
the compiler, to stop people arguing about code formatting. Just because
people keep saying something, doesn't make it right.



> If the old guard starts to push back as much as I have seen here, we are
> going to lose momentum as a community and have people not willing to work
> on PHP as much.
>


I feel like the opposite: if people volunteering their time find that all
their energy is spent on pointless arguments about removing working
features, and none of it is spent on actually innovating the language,
they'll spend it somewhere else.



> Long story short - indecision is not an option.



Here's a decision for you then: short tags are fine how they are, and we
can stop wasting energy talking about them and get on with doing something
that actually benefits the language. That's not indecision, that's a
concrete position we could take to prioritise our efforts on something more
productive.


The previous RFC has
> passed. Everyone involved, I hope, understands that yes, there will be
> stuff going wrong for some users who are careless and/or ignorant and live
> under a rock. Can we really do anything about that?



Yes. Yes, we can. We can do what's proposed in the v2 RFC, or we can
reverse our decision. An RFC passing isn't a pact with the devil.



> Let's look into the future, use a reasonable amount of caution and/or
> deprecation notice periods, but please stop trying to block features
>


What is the feature being blocked if we leave short tags in PHP? If such a
feature existed, I would understand your frustration - but if it did, the
RFC could make the case for why adding that new feature was worth the pain
caused by removing the old feature. Since there is no such feature, there
is no such justification in the RFC, which is why it's so controversial.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Thu, Aug 8, 2019 at 10:42 AM Peter Kokot  wrote:

> Hello,
>
> On Thu, 8 Aug 2019 at 16:17, Chase Peeler  wrote:
> >
> > On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski  wrote:
> >
> > > On Thu, Aug 8, 2019 at 3:17 PM Brent  wrote:
> > >
> > > > I asked similar questions on Twitter, where Zeev replied the
> following:
> > > > https://mobile.twitter.com/zeevs/status/115865658046464
> > >
> > >
> > > I want to add a bit of color to this tweet:
> > > - Estimated # of developers using PHP is at around 10M.  This is based
> on
> > > some extrapolation from an EDS report from ~8 years ago that estimated
> that
> > > number at >6M, and growth rates we've seen beforehand.
> > > - Anecdotally, I've seen it used many times in non-distributable code
> over
> > > the years - a lot more frequently than once per 100 users.
> > > - Even if just 1% of the userbase uses short tags, that's ~100K.  We
> can
> > > call this one a guess, but I'd say it's an educated guess that there's
> well
> > > above 1% of the PHP userbase that uses short tags.
> > >
> > > It feels like much of the counter arguments are based on guesses
> without
> > > > any real data to point to.
> > >
> > >
> > > I wouldn't say they're guesses, but extrapolations - for instance, the
> fact
> > > I'm aware of many PHP frameworks and apps, and am not aware of any
> single
> > > one that allows short tags - makes me feel fairly comfortable to make
> the
> > > statement that "virtually all frameworks and apps designed for public
> > > consumption disallow short tags".  I can't preclude the possibility
> that
> > > the fact that all of the apps and frameworks I'm aware of don't allow
> short
> > > tags is a remarkable coincidence - or that there are countless ones
> I'm not
> > > aware of that do allow short tags - but I think that my theory is a lot
> > > more plausible.
> > >
> > > I work on an internal application. Even though portability is not a
> > concern for anything we write, we haven't used short tags since it was
> > rumored they were going to be removed in PHP 6 many years ago. That being
> > said, this application has been in development since 2003. There is a
> large
> > amount of legacy code written before I even started here, not to mention
> > plenty of horrible code written after I did start in 2005 (this was my
> > first job). As I mentioned in an email on this thread yesterday, most of
> > our legacy code is "just leave it alone, it works" code. We are in the
> > process of rewriting things, but, that takes time. We try and mess with
> the
> > legacy code as little as possible. Something as simple as auto formatting
> > with PhpStorm has broken things in the past - so I don't trust an
> automated
> > tool to fix the short tags for me. Even if I'm the only person that has
> > participated in this thread that has to maintain a codebase that consists
> > of non-portable code with a large amount of short tags, that's still at
> > least 1% of those that have participated in this thread, or one of its
> > predecessors.
> >
> > Another thing to keep in mind is that most of the people writing and/or
> > maintaining "non-portable" code probably don't work for a company in the
> > software development industry. When I want to upgrade PHP, I have to
> > convince our leadership of the value of me spending a couple of weeks
> > fixing BC breaks. I have to show why that is more valuable than spending
> > time on the development of new functionality. The more time required to
> do
> > an upgrade, the more likely it will get punted to a future date.
> >
> > I'm not against BC breaks in general - they are a necessary evil.
> However,
> > it's important that the negative impact of that break is far outweighed
> by
> > the positive value it brings. I'll leave it up to each of you to
> determine
> > how positive of an impact removing short tags would bring. I can promise
> > you, though, that the negative impact would be VERY large. Just because
> you
> > don't personally have to maintain any code that uses short tags doesn't
> > mean that there aren't other developers out there that do. Every BC break
> > is going to lead to a subset of users that will decide to not upgrade as
> a
> > result. It will also lead to a subset of users that will decide to use a
> > different technology (node, .NET, python, etc.) going forward. Many BC
> > breaks are worth that risk. Is this one of them?
> >
> > Many people have talked about the potential impacts of keeping short
> tags.
> > I have yet to see anyone give an actual example where they have been
> > negatively impacted by their existence. I've given you my personal story
> of
> > how removing them will negatively impact my company. I welcome anyone
> that
> > can provide an actual incident where the existence of short tags hurt
> them,
> > or, the continued existence is likely to have a large negative impact on
> > them in the future.
> >
> >
> > > Zeev
> > >
> >
> >
> > --
> > Chase Peeler
> > 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Arvids Godjuks]

чт, 8 авг. 2019 г. в 16:42, Peter Kokot :

> Hello,
> Thanks for sharing your stories about issues. Maybe we should start
> also thinking about the impact on the language attractiveness to pick
> it when starting a new web project since the core people can't come to
> conclusions how to make the language more consistent on the long run
> (PHP 9 etc)... With more and more ambiguities, inconsistencies,
> lockups, and dead ends behind the language there is probably also a
> bit of a factor to consider that it lowers this attractiveness.
> Meaning less people will think of adopting it (with all the things
> combined - short tags, that and that inconsistency not being removed
> from PHP due to major disastrous BC break there and there). So, the
> damage is also on the long run with more and more locks and dead ends
> not being able to be fixed and cleaned.
>
>
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hello.

Peter above put my thoughts perfectly.

BC is great, but you need to pull the cord at some point. And the whole
short tag back and forth, with deprecation warning and stuff, has been
around for last half a decade. It is time to accept that it needs to go and
there should be no runtime dependent switch for this. Valid PHP tags are
`https://t.me/psihius

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello,

On Thu, 8 Aug 2019 at 16:17, Chase Peeler  wrote:
>
> On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski  wrote:
>
> > On Thu, Aug 8, 2019 at 3:17 PM Brent  wrote:
> >
> > > I asked similar questions on Twitter, where Zeev replied the following:
> > > https://mobile.twitter.com/zeevs/status/115865658046464
> >
> >
> > I want to add a bit of color to this tweet:
> > - Estimated # of developers using PHP is at around 10M.  This is based on
> > some extrapolation from an EDS report from ~8 years ago that estimated that
> > number at >6M, and growth rates we've seen beforehand.
> > - Anecdotally, I've seen it used many times in non-distributable code over
> > the years - a lot more frequently than once per 100 users.
> > - Even if just 1% of the userbase uses short tags, that's ~100K.  We can
> > call this one a guess, but I'd say it's an educated guess that there's well
> > above 1% of the PHP userbase that uses short tags.
> >
> > It feels like much of the counter arguments are based on guesses without
> > > any real data to point to.
> >
> >
> > I wouldn't say they're guesses, but extrapolations - for instance, the fact
> > I'm aware of many PHP frameworks and apps, and am not aware of any single
> > one that allows short tags - makes me feel fairly comfortable to make the
> > statement that "virtually all frameworks and apps designed for public
> > consumption disallow short tags".  I can't preclude the possibility that
> > the fact that all of the apps and frameworks I'm aware of don't allow short
> > tags is a remarkable coincidence - or that there are countless ones I'm not
> > aware of that do allow short tags - but I think that my theory is a lot
> > more plausible.
> >
> > I work on an internal application. Even though portability is not a
> concern for anything we write, we haven't used short tags since it was
> rumored they were going to be removed in PHP 6 many years ago. That being
> said, this application has been in development since 2003. There is a large
> amount of legacy code written before I even started here, not to mention
> plenty of horrible code written after I did start in 2005 (this was my
> first job). As I mentioned in an email on this thread yesterday, most of
> our legacy code is "just leave it alone, it works" code. We are in the
> process of rewriting things, but, that takes time. We try and mess with the
> legacy code as little as possible. Something as simple as auto formatting
> with PhpStorm has broken things in the past - so I don't trust an automated
> tool to fix the short tags for me. Even if I'm the only person that has
> participated in this thread that has to maintain a codebase that consists
> of non-portable code with a large amount of short tags, that's still at
> least 1% of those that have participated in this thread, or one of its
> predecessors.
>
> Another thing to keep in mind is that most of the people writing and/or
> maintaining "non-portable" code probably don't work for a company in the
> software development industry. When I want to upgrade PHP, I have to
> convince our leadership of the value of me spending a couple of weeks
> fixing BC breaks. I have to show why that is more valuable than spending
> time on the development of new functionality. The more time required to do
> an upgrade, the more likely it will get punted to a future date.
>
> I'm not against BC breaks in general - they are a necessary evil. However,
> it's important that the negative impact of that break is far outweighed by
> the positive value it brings. I'll leave it up to each of you to determine
> how positive of an impact removing short tags would bring. I can promise
> you, though, that the negative impact would be VERY large. Just because you
> don't personally have to maintain any code that uses short tags doesn't
> mean that there aren't other developers out there that do. Every BC break
> is going to lead to a subset of users that will decide to not upgrade as a
> result. It will also lead to a subset of users that will decide to use a
> different technology (node, .NET, python, etc.) going forward. Many BC
> breaks are worth that risk. Is this one of them?
>
> Many people have talked about the potential impacts of keeping short tags.
> I have yet to see anyone give an actual example where they have been
> negatively impacted by their existence. I've given you my personal story of
> how removing them will negatively impact my company. I welcome anyone that
> can provide an actual incident where the existence of short tags hurt them,
> or, the continued existence is likely to have a large negative impact on
> them in the future.
>
>
> > Zeev
> >
>
>
> --
> Chase Peeler
> chasepee...@gmail.com

Thanks for sharing your stories about issues. Maybe we should start
also thinking about the impact on the language attractiveness to pick
it when starting a new web project since the core people can't come to
conclusions how to make the language more consistent on the long run

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski  wrote:

> On Thu, Aug 8, 2019 at 3:17 PM Brent  wrote:
>
> > I asked similar questions on Twitter, where Zeev replied the following:
> > https://mobile.twitter.com/zeevs/status/115865658046464
>
>
> I want to add a bit of color to this tweet:
> - Estimated # of developers using PHP is at around 10M.  This is based on
> some extrapolation from an EDS report from ~8 years ago that estimated that
> number at >6M, and growth rates we've seen beforehand.
> - Anecdotally, I've seen it used many times in non-distributable code over
> the years - a lot more frequently than once per 100 users.
> - Even if just 1% of the userbase uses short tags, that's ~100K.  We can
> call this one a guess, but I'd say it's an educated guess that there's well
> above 1% of the PHP userbase that uses short tags.
>
> It feels like much of the counter arguments are based on guesses without
> > any real data to point to.
>
>
> I wouldn't say they're guesses, but extrapolations - for instance, the fact
> I'm aware of many PHP frameworks and apps, and am not aware of any single
> one that allows short tags - makes me feel fairly comfortable to make the
> statement that "virtually all frameworks and apps designed for public
> consumption disallow short tags".  I can't preclude the possibility that
> the fact that all of the apps and frameworks I'm aware of don't allow short
> tags is a remarkable coincidence - or that there are countless ones I'm not
> aware of that do allow short tags - but I think that my theory is a lot
> more plausible.
>
> I work on an internal application. Even though portability is not a
concern for anything we write, we haven't used short tags since it was
rumored they were going to be removed in PHP 6 many years ago. That being
said, this application has been in development since 2003. There is a large
amount of legacy code written before I even started here, not to mention
plenty of horrible code written after I did start in 2005 (this was my
first job). As I mentioned in an email on this thread yesterday, most of
our legacy code is "just leave it alone, it works" code. We are in the
process of rewriting things, but, that takes time. We try and mess with the
legacy code as little as possible. Something as simple as auto formatting
with PhpStorm has broken things in the past - so I don't trust an automated
tool to fix the short tags for me. Even if I'm the only person that has
participated in this thread that has to maintain a codebase that consists
of non-portable code with a large amount of short tags, that's still at
least 1% of those that have participated in this thread, or one of its
predecessors.

Another thing to keep in mind is that most of the people writing and/or
maintaining "non-portable" code probably don't work for a company in the
software development industry. When I want to upgrade PHP, I have to
convince our leadership of the value of me spending a couple of weeks
fixing BC breaks. I have to show why that is more valuable than spending
time on the development of new functionality. The more time required to do
an upgrade, the more likely it will get punted to a future date.

I'm not against BC breaks in general - they are a necessary evil. However,
it's important that the negative impact of that break is far outweighed by
the positive value it brings. I'll leave it up to each of you to determine
how positive of an impact removing short tags would bring. I can promise
you, though, that the negative impact would be VERY large. Just because you
don't personally have to maintain any code that uses short tags doesn't
mean that there aren't other developers out there that do. Every BC break
is going to lead to a subset of users that will decide to not upgrade as a
result. It will also lead to a subset of users that will decide to use a
different technology (node, .NET, python, etc.) going forward. Many BC
breaks are worth that risk. Is this one of them?

Many people have talked about the potential impacts of keeping short tags.
I have yet to see anyone give an actual example where they have been
negatively impacted by their existence. I've given you my personal story of
how removing them will negatively impact my company. I welcome anyone that
can provide an actual incident where the existence of short tags hurt them,
or, the continued existence is likely to have a large negative impact on
them in the future.


> Zeev
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Zeev Suraski]

On Thu, Aug 8, 2019 at 3:17 PM Brent  wrote:

> I asked similar questions on Twitter, where Zeev replied the following:
> https://mobile.twitter.com/zeevs/status/115865658046464


I want to add a bit of color to this tweet:
- Estimated # of developers using PHP is at around 10M.  This is based on
some extrapolation from an EDS report from ~8 years ago that estimated that
number at >6M, and growth rates we've seen beforehand.
- Anecdotally, I've seen it used many times in non-distributable code over
the years - a lot more frequently than once per 100 users.
- Even if just 1% of the userbase uses short tags, that's ~100K.  We can
call this one a guess, but I'd say it's an educated guess that there's well
above 1% of the PHP userbase that uses short tags.

It feels like much of the counter arguments are based on guesses without
> any real data to point to.


I wouldn't say they're guesses, but extrapolations - for instance, the fact
I'm aware of many PHP frameworks and apps, and am not aware of any single
one that allows short tags - makes me feel fairly comfortable to make the
statement that "virtually all frameworks and apps designed for public
consumption disallow short tags".  I can't preclude the possibility that
the fact that all of the apps and frameworks I'm aware of don't allow short
tags is a remarkable coincidence - or that there are countless ones I'm not
aware of that do allow short tags - but I think that my theory is a lot
more plausible.

Zeev

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Collins]

On 8 August 2019 13:16:56 BST, Brent  wrote:
>I asked similar questions on Twitter, where Zeev replied the
>following:
>
>> With an estimated number of PHP developers
>> at 10M, 1% is 100K. Whether I know this for
>> sure is not at all the point - it's never how we
>> take decisions. The question is whether it's
>> reasonable or not. And my guess is that a lot
>> more than 1% uses short tags.
>
>It feels like much of the counter arguments are based on guesses
>without any real data to point to.


You can take that both ways though: the argument that short tags should be 
removed is based on the same guesses. 

I understand Zeev's frustration in being asked to provide the proof when his 
position is that we shouldn't be spending any time on the issue at all. It 
should be up to those who think a change is necessary to demonstrate both the 
harm of the status quo (e.g. real-world cases of code exposure), and that it 
outweighs the cost of change (e.g. how many users will need to change working 
code).

It would be different if we were choosing between two versions of some feature, 
but no-change should always have a starting advantage over change, which is why 
we require a super-majority in primary RFC votes.

Regards,
-- 
Rowan Collins
[IMSoP]

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> -Original Message-
> From: Brent [mailto:bre...@stitcher.io]
>
>
> It feels like much of the counter arguments are based on guesses without any
> real data to point to.

It goes both ways - the argument for removal states "This means that their use 
is not possible in portable code, because the code author does not necessarily 
have the necessary control over the configuration".

What is the number/statistics of developers which have written a portable (in 
their mind) code (which means NOT using short tags) just to find out that the 
code/application doesn't work because those are disabled?

Is there real data for that?

rr 


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Brent]

I asked similar questions on Twitter, where Zeev replied the following: 
https://mobile.twitter.com/zeevs/status/115865658046464

It feels like much of the counter arguments are based on guesses without any 
real data to point to. On the other hand it's unfair to dismiss the counter 
arguments altogether because of this, as there's no way to gather accurate data 
about the usage of short open tags, let alone know how many developers using 
them actually plan on ever upgrading to 7.4…

Kind regards
Brent
On 8 Aug 2019, 12:27 +0200, Côme Chilliet , wrote:
> Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :
> > Pretty much everyone (if not actually
> > everyone) that is against this RFC has stated that they don't actually use
> > short tags, and do not advocate that anyone else use them either.
>
> This is what bugs me, the counter argument page from Zeev states «I never use 
> short tags in any PHP code that I write, and as far as I recall - I never 
> have. »,
> and at the same time «put hundreds of thousands of people through additional 
> pain when upgrading.»
>
> Is there any data that support the theory that hundreds of thousands of 
> people use short tags?
>
> Did anyone in this discussion stated that he was using them?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Collins]

On Wed, 7 Aug 2019 at 20:45, Sergey Panteleev  wrote:

> Hi there!
>
> Perhaps I missed and someone already suggested,
> but didn't consider a compromise option:
> just change the default value short_open_tag=false,
> and DON'T removes the option from php.ini?
>
> If someone uses short tags - ok, they will change
> the default value to true and everything will be as before,
> who won't change it - will enjoy the full syntax
>


Defaulting it to "off" would risk leaking people's code if they didn't set
it, but I suggested earlier that it could default to a new "error" mode
(which could also be explicitly set):
https://externals.io/message/106384#106408

Regards,
-- 
Rowan Collins
[IMSoP]

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Reinis Rozitis]

> -Original Message-
> From: Côme Chilliet [mailto:c...@opensides.be]
>
> This is what bugs me, the counter argument page from Zeev states «I never
> use short tags in any PHP code that I write, and as far as I recall - I never
> have. »,  and at the same time «put hundreds of thousands of people
> through additional pain when upgrading.»

Why does/should it bug you? The statements aren't contradictory. 
There are (must be) a lot of features which a particular language developer 
might not use (or even find ridiculous) himself personally but those still have 
been implemented historically or for future use for other users/clients etc.


> Did anyone in this discussion stated that he was using them?

Yes.

rr


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Côme Chilliet]

Le mercredi 7 août 2019, 15:57:02 CEST Chase Peeler a écrit :
> Pretty much everyone (if not actually
> everyone) that is against this RFC has stated that they don't actually use
> short tags, and do not advocate that anyone else use them either.

This is what bugs me, the counter argument page from Zeev states «I never use 
short tags in any PHP code that I write, and as far as I recall - I never have. 
»,
 and at the same time «put hundreds of thousands of people through additional 
pain when upgrading.»

Is there any data that support the theory that hundreds of thousands of people 
use short tags?

Did anyone in this discussion stated that he was using them?

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Thu, 8 Aug 2019 at 00:38, Zeev Suraski  wrote:
>
>
>
> On Thu, Aug 8, 2019 at 12:39 AM Peter Kokot  wrote:
>>
>> Thank you for such a detailed response. Ok, I understand then. Then
>> next logical step here is - I would maybe want to use these awesome
>> short tags also then.
>
>
> No disrespect Peter, but I really don't think you understand (my position).
>
> I don't think there's anything awesome about short tags.  I don't think 
> there's anything evil about them either.  They are what they are, what they 
> have been for the last two decades.  They didn't cause any damage to PHP, and 
> they won't start causing damage to PHP in the future.
> Personally, I like the verbose version a lot more, I like the verbosity.  I'm 
> capable of holding that preference in my mind alongside realizing that others 
> have a different preference.  I'm not missionary about my tag preferences, 
> and neither should you.
>
>
>> So, why not enabling these short tags everywhere then and suggesting
>> in the PHP manual that they can be used again in PHP x.y version etc?
>
>
> As much as it's an uncommon use case - I think making PHP inherently 
> incompatible with XML is not a good idea.  As I mentioned, personally I also 
> prefer the verbosity as well as the free PHP publicity in every tag.
>
> But a more fundamental level, I really fail to see any good reason to be 
> spending our brain cycles on this matter (yes, I realize that we're waaay too 
> late, but better late than never).
> This is a non-issue, that we suddenly made into an issue, and now we need to 
> discuss it, come up with pros and cons, debate them, write lengthy proposals 
> and counterarguments - and for what?  For dealing with a non-issue.
> Can we turn this issue back into the non-issue that it is?
>
> Zeev

I can do that. I just wanted to get some more possible explanations,
because there isn't any guideline why these tags are (still) in PHP
and why someone would want to use them (because this is the case
actually). Now, I think we all understand better here. No. 1 reason
they are (still) there is the legacy code support - understandable.
They in its core essence shouldn't be used and are discouraged further
on as manual suggests. Many languages would make these "obsolete"
somehow (probably) I think but ok if they are meant to be in, so be
it...

And maybe also for the community out there to understand this entire
issue better and the outcome of the RFC whatever it is when voting
ends.

Have a nice day forward...

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Zeev Suraski]

On Thu, Aug 8, 2019 at 12:39 AM Peter Kokot  wrote:

> Thank you for such a detailed response. Ok, I understand then. Then
> next logical step here is - I would maybe want to use these awesome
> short tags also then.


No disrespect Peter, but I really don't think you understand (my position).

I don't think there's anything awesome about short tags.  I don't think
there's anything evil about them either.  They are what they are, what they
have been for the last two decades.  They didn't cause any damage to PHP,
and they won't start causing damage to PHP in the future.
Personally, I like the verbose version a lot more, I like the verbosity.
I'm capable of holding that preference in my mind alongside realizing that
others have a different preference.  I'm not missionary about my tag
preferences, and neither should you.


So, why not enabling these short tags everywhere then and suggesting
> in the PHP manual that they can be used again in PHP x.y version etc?
>

As much as it's an uncommon use case - I think making PHP inherently
incompatible with XML is not a good idea.  As I mentioned, personally I
also prefer the verbosity as well as the free PHP publicity in every tag.

But a more fundamental level, I really fail to see any good reason to be
spending our brain cycles on this matter (yes, I realize that we're waaay
too late, but better late than never).
This is a non-issue, that we suddenly made into an issue, and now we need
to discuss it, come up with pros and cons, debate them, write lengthy
proposals and counterarguments - and for what?  For dealing with a
non-issue.
Can we turn this issue back into the non-issue that it is?

Zeev

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 7 Aug 2019 at 21:25, Zeev Suraski  wrote:
>
>
>
> On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot  wrote:
>>
>> Considering that you're in favor of keeping the short opening tag in
>>
>> PHP "forever" because you haven't added any kind of other solution
>> either by now neither you see an issue with this... I think the worst
>> situation for language is that there is an option to write non
>> portable code with this unfortunate short tag.
>
>
> Peter,
>
> To put it simply - many of us simply don't see an issue if short tags are 
> with us even at PHP 99, centuries after we're no longer around.  We certainly 
> don't see an issue if it sticks with us until PHP 10.
>
> In fact, it's not that we don't think it's an issue - we actually think 
> that's a Good Thing if it stays, and a Bad Thing if it's removed.
>
> I did my best to illustrate why I think that is the case in my 
> Counterargument 
> (https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags).  I 
> accept that you see things differently.  However, please accept that we also 
> see things differently and are entitled to our opinion just as much as you 
> are entitled to yours.  We simply fail to see an issue with short tags that 
> comes even close for us to want to remove it.  It's not even a close call.  A 
> zero gain and substantial pain associated with a deprecation should be an 
> obvious choice.
>
> To quote Sara Golemon:
> "Frankly, I can't understand why anyone *does* want to drop it."
> (https://twitter.com/SaraMG/status/1158936328450576384)
>
> PHP always had a bias for downwards compatibility.  We went out of our way to 
> come up with creative ways to reinvent the brain of the language several 
> times - while going through hoops to keep code behavior identical.  We did 
> not shy away from breaking compatibility when there was a very strong case - 
> such as the OO model between PHP 4 and 5, the deprecation of magic quotes and 
> the deprecation of safe mode - all painful migrations, but with a very, very 
> strong case that goes well beyond "having more than one way of doing things" 
> or "this creates the possibility of non-portable code".  TBH, I expected 
> folks who are joining the project to accept that, although I guess I was 
> naive as this is clearly not happening (it's only implied in the 'rules', but 
> not actually codified).
>
> Repeating what I said a couple of weeks ago - it seems we've now switched to 
> the business of breaking things almost for the sake of breaking things, and 
> it's really disheartening.
>
> Many of us think that removing short tags does absolutely nothing to improve 
> the portability of PHP code.
>
> I'll go beyond that - the ability to create non-portable code should never be 
> grounds by itself for deprecating a feature (it can be a contributing 
> factor).  There are endless elements that an app can use that can make it non 
> portable.  For example, should we be deprecating support for all databases 
> other than SQLite?  After all, they may not always be installed.  Should we 
> deprecate the SHM extension?  People using it may be stuck if they ever try 
> to deploy to Windows.  What about deprecating disable_functions?  It's a 
> portability disaster that's just waiting to happen.  And I barely even got 
> started.  Almost anything beyond pure PHP logic may not work in all 
> environments, and it's absolutely fine.  It also constitutes absolutely no 
> grounds for starting to go around axing features.
>
> Thankfully, fact is, not all code has to be portable.  The important thing is 
> that those who want to write portable code will be able to do so - while not 
> forcing everyone else to write portable code by enforcing the lowest common 
> denominator.
> I think Chase alluded to the fact that there's substantial anecdotal evidence 
> that the availability of short tags did not actually cause any trouble in the 
> last 20 years.  And when I say anecdotal evidence - I mean that some of the 
> most popular applications on the Web (including the top 3 most popular ones) 
> have been written in PHP, and there's a gigantic framework ecosystem around 
> PHP.
>
> I realize that you think it's a problem that we have two opening tags for PHP 
> - and a major one at that.  It's entirely your right to do so and I 
> wholeheartedly accept it.  Similarly, please accept it that I, as well as 
> many others, simply don't view this as a problem.  And when one does not 
> think there's a problem, one typically does not spend time finding solutions.
>
> FWIW, if for whatever reason I did think it was a problem - I think the 
> updated V2 RFC would be the best way to solve it.  But I don't.
>
> With all that said, I still think there may be a solution that can make 
> mostly everyone happy, or at least not really unhappy.  It may even include 
> deprecating short tags (in a way) - but more importantly - overhauling much 
> more important elements in PHP as well.  I hope to bring it up for some 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Robert Korulczyk]

> PHP is, after all, built almost entirely on extensions. Those extensions can 
> either be there, or not, enabled in the INI, or not. Do we consider code
> written containing functions from mysqli, gd or zip (just to name a few) to 
> be non-portable because we can omit them from the INI (or just not install
> them).

These are completely different things. In case of extensions, you can check 
whether the extension is installed, you can react on lack of it, and you
can require extension as part of composer constraints (sometimes you can just 
use polyfill). And at worst case, you will get a fatal error that will
tell you that there is something wrong with your code/environment.
Neither of it is true for short tags - your code is just silently displayed. 
And you can't do anything about it, because you're code is no longer a code.


> IMHO short tag removal has one major thing going for it, consistency, and by 
> extension, predictability.
> 
> That's it.

For me, the main reason to remove short tags are code leaks. As long as there 
will be an option to disable short open tags support, there will be code
leaks. Now there is a chance to remove one source of WTFs in PHP and end this 
code leaks problem once and for all. The migration may be problematic
for fraction of applications, but at least this is a one-time process, well 
documented and preceded by a long deprecation period. The alternative is
current state when code leaks just unexpectedly pop out without any warning and 
explanation (exception "It's PHP, deal with it").


Regards,
Robert Korulczyk

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Wed, Aug 7, 2019 at 1:14 PM Nicolas Grekas 
wrote:

> Le mar. 6 août 2019 à 13:34, G. P. B.  a écrit :
>
> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> > It is expected to last two (2) weeks until 2019-08-20.
> >
> > A counter argument to this RFC is available at
> > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> >
> > Best regards
> >
> > George P. Banyard
> >
> > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>
>
>
> The counter-arguments are a really nice addition to the process.
>
> Reading them made me think there is a big missing "pro" argument: perceived
> complexity of the engine.
>
> When there is no choice to make (short tags on/off, magic_quote on/off,
> etc), then there is only one thing to teach, one thing to learn, one thing
> to (not have to) agree on when deciding for some conventions, etc.
>
> When there are N binary options (and not all options are binary), there are
> 2^N things to teach, learn, etc.
>
> In this case, claiming a slippery-slope is a logical fallacy. We aren't
talking about opening it up so that we can add even more opening tags in
the future. The odds are pretty much zero that keeping short tags would
lead to it in the future. We're talking about two possible ways to begin a
block of PHP code.  That's a major cost put on the community. Choices that were made years ago
> when PHP was not what it is today were certainly fine, but nowadays, this
> imposes significant a burden on everyone. Each option individually are
> maybe minor, but the 2^N becomes quickly big. I think we should make such
> things way simpler so that we can free the brains of many to do the next
> things that matter.
>
> I think the cost put on the community to fix existing instances of short
tags is a MUCH higher burden than asking them know about the existence of
short tags should they encounter them one day. I'm in charge of maintaining
a very large legacy code base. The majority of the legacy code is "leave it
alone code" that is slowly getting re-written. The code is horrendous.
Things have broken in the past from running PhpStorm's auto-formatting on a
file. The effort required to update all of that code in order to upgrade
would be so high that it's likely I would never get approval from my
superiors to spend that much time on it.


> I don't have a vote, but if I were I would vote "yes". Instead, I encourage
> "no"-voters to reconsider, and others to vote "yes" too :)
>
> Cheers,
> Nicolas
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags,again

[Mark Randall]

On 07/08/2019 20:45, Sergey Panteleev wrote:

Perhaps I missed and someone already suggested,
but didn't consider a compromise option:
just change the default value short_open_tag=false,
and DON'T removes the option from php.ini?


Without the other changes, this would lead to potentially dangerous code 
and data leakage.


It's not really viable to simply change the default, or remove the 
option, without creating a significant security risk.


Upgrading from one version to the next, without explicitly specifying 
the configuration in the INI during the upgrade  (if previously 
omitted), would treat code which was previously explicitly specified as 
valid, as no longer valid, and would expose it to the world.


Mark Randall

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Sergey Panteleev]

Hi there!

Perhaps I missed and someone already suggested,
but didn't consider a compromise option:
just change the default value short_open_tag=false,
and DON'T removes the option from php.ini?

If someone uses short tags - ok, they will change
the default value to true and everything will be as before,
who won't change it - will enjoy the full syntax

—
Sincerely,
Sergey Panteleev
https://s-panteleev.ru
Phone: +7 (906) 634-79-37
Telegram: @saundefined
E-mail: ser...@s-panteleev.ru
On 7 Aug 2019, 22:25 +0300, Zeev Suraski , wrote:
> On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot  wrote:
>
> > Considering that you're in favor of keeping the short opening tag in
> >
> PHP "forever" because you haven't added any kind of other solution
> > either by now neither you see an issue with this... I think the worst
> > situation for language is that there is an option to write non
> > portable code with this unfortunate short tag.
>
>
> Peter,
>
> To put it simply - many of us simply don't see an issue if short tags are
> with us even at PHP 99, centuries after we're no longer around. We
> certainly don't see an issue if it sticks with us until PHP 10.
>
> In fact, it's not that we don't think it's an issue - we actually think
> that's a Good Thing if it stays, and a Bad Thing if it's removed.
>
> I did my best to illustrate why I think that is the case in my
> Counterargument (
> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags). I
> accept that you see things differently. However, please accept that we
> also see things differently and are entitled to our opinion just as much as
> you are entitled to yours. We simply fail to see an issue with short tags
> that comes even close for us to want to remove it. It's not even a close
> call. A zero gain and substantial pain associated with a deprecation
> should be an obvious choice.
>
> To quote Sara Golemon:
> "Frankly, I can't understand why anyone *does* want to drop it."
> (https://twitter.com/SaraMG/status/1158936328450576384)
>
> PHP always had a bias for downwards compatibility. We went out of our way
> to come up with creative ways to reinvent the brain of the language several
> times - while going through hoops to keep code behavior identical. We did
> not shy away from breaking compatibility when there was a very strong case
> - such as the OO model between PHP 4 and 5, the deprecation of magic quotes
> and the deprecation of safe mode - all painful migrations, but with a very,
> very strong case that goes well beyond "having more than one way of doing
> things" or "this creates the possibility of non-portable code". TBH, I
> expected folks who are joining the project to accept that, although I guess
> I was naive as this is clearly not happening (it's only implied in the
> 'rules', but not actually codified).
>
> Repeating what I said a couple of weeks ago - it seems we've now switched
> to the business of breaking things almost for the sake of breaking things,
> and it's really disheartening.
>
> Many of us think that removing short tags does *absolutely nothing* to
> improve the portability of PHP code.
>
> I'll go beyond that - the ability to create non-portable code should never
> be grounds by itself for deprecating a feature (it can be a contributing
> factor). There are endless elements that an app can use that can make it
> non portable. For example, should we be deprecating support for all
> databases other than SQLite? After all, they may not always be installed.
> Should we deprecate the SHM extension? People using it may be stuck if
> they ever try to deploy to Windows. What about deprecating
> disable_functions? It's a portability disaster that's just waiting to
> happen. And I barely even got started. Almost anything beyond pure PHP
> logic may not work in all environments, and it's absolutely fine. It also
> constitutes absolutely no grounds for starting to go around axing features.
>
> Thankfully, fact is, not all code has to be portable. The important thing
> is that those who want to write portable code will be able to do so - while
> not forcing everyone else to write portable code by enforcing the lowest
> common denominator.
> I think Chase alluded to the fact that there's substantial anecdotal
> evidence that the availability of short tags did not actually cause any
> trouble in the last 20 years. And when I say anecdotal evidence - I mean
> that some of the most popular applications on the Web (including the top 3
> most popular ones) have been written in PHP, and there's a gigantic
> framework ecosystem around PHP.
>
> I realize that you think it's a problem that we have two opening tags for
> PHP - and a major one at that. It's entirely your right to do so and I
> wholeheartedly accept it. Similarly, please accept it that I, as well as
> many others, simply don't view this as a problem. And when one does not
> think there's a problem, one typically does not spend time finding
> solutions.
>
> FWIW, if for whatever reason 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Zeev Suraski]

On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot  wrote:

> Considering that you're in favor of keeping the short opening tag in
>
PHP "forever" because you haven't added any kind of other solution
> either by now neither you see an issue with this... I think the worst
> situation for language is that there is an option to write non
> portable code with this unfortunate short tag.


Peter,

To put it simply - many of us simply don't see an issue if short tags are
with us even at PHP 99, centuries after we're no longer around.  We
certainly don't see an issue if it sticks with us until PHP 10.

In fact, it's not that we don't think it's an issue - we actually think
that's a Good Thing if it stays, and a Bad Thing if it's removed.

I did my best to illustrate why I think that is the case in my
Counterargument (
https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags).  I
accept that you see things differently.  However, please accept that we
also see things differently and are entitled to our opinion just as much as
you are entitled to yours.  We simply fail to see an issue with short tags
that comes even close for us to want to remove it.  It's not even a close
call.  A zero gain and substantial pain associated with a deprecation
should be an obvious choice.

To quote Sara Golemon:
"Frankly, I can't understand why anyone *does* want to drop it."
(https://twitter.com/SaraMG/status/1158936328450576384)

PHP always had a bias for downwards compatibility.  We went out of our way
to come up with creative ways to reinvent the brain of the language several
times - while going through hoops to keep code behavior identical.  We did
not shy away from breaking compatibility when there was a very strong case
- such as the OO model between PHP 4 and 5, the deprecation of magic quotes
and the deprecation of safe mode - all painful migrations, but with a very,
very strong case that goes well beyond "having more than one way of doing
things" or "this creates the possibility of non-portable code".  TBH, I
expected folks who are joining the project to accept that, although I guess
I was naive as this is clearly not happening (it's only implied in the
'rules', but not actually codified).

Repeating what I said a couple of weeks ago - it seems we've now switched
to the business of breaking things almost for the sake of breaking things,
and it's really disheartening.

Many of us think that removing short tags does *absolutely nothing* to
improve the portability of PHP code.

I'll go beyond that - the ability to create non-portable code should never
be grounds by itself for deprecating a feature (it can be a contributing
factor).  There are endless elements that an app can use that can make it
non portable.  For example, should we be deprecating support for all
databases other than SQLite?  After all, they may not always be installed.
Should we deprecate the SHM extension?  People using it may be stuck if
they ever try to deploy to Windows.  What about deprecating
disable_functions?  It's a portability disaster that's just waiting to
happen.  And I barely even got started.  Almost anything beyond pure PHP
logic may not work in all environments, and it's absolutely fine.  It also
constitutes absolutely no grounds for starting to go around axing features.

Thankfully, fact is, not all code has to be portable.  The important thing
is that those who want to write portable code will be able to do so - while
not forcing everyone else to write portable code by enforcing the lowest
common denominator.
I think Chase alluded to the fact that there's substantial anecdotal
evidence that the availability of short tags did not actually cause any
trouble in the last 20 years.  And when I say anecdotal evidence - I mean
that some of the most popular applications on the Web (including the top 3
most popular ones) have been written in PHP, and there's a gigantic
framework ecosystem around PHP.

I realize that you think it's a problem that we have two opening tags for
PHP - and a major one at that.  It's entirely your right to do so and I
wholeheartedly accept it.  Similarly, please accept it that I, as well as
many others, simply don't view this as a problem.  And when one does not
think there's a problem, one typically does not spend time finding
solutions.

FWIW, if for whatever reason I did think it was a problem - I think the
updated V2 RFC would be the best way to solve it.  But I don't.

With all that said, I still think there may be a solution that can make
mostly everyone happy, or at least not really unhappy.  It may even include
deprecating short tags (in a way) - but more importantly - overhauling much
more important elements in PHP as well.  I hope to bring it up for some
initial brainstorming (not RFC level, just gauging response) tomorrow.

Zeev

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Mark Randall]

On 07/08/2019 18:44, Peter Kokot wrote:

I think the worst
situation for language is that there is an option to write non
portable code with this unfortunate short tag. It won't work
everywhere. So, this is already a reason for thinking forward (at
least from the progress and consistency point of view)


I feel it necessary to point out that non-portability due to INI 
settings applies to almost everything PHP does, and in and of itself 
should not be considered a major argument.


PHP is, after all, built almost entirely on extensions. Those extensions 
can either be there, or not, enabled in the INI, or not. Do we consider 
code written containing functions from mysqli, gd or zip (just to name a 
few) to be non-portable because we can omit them from the INI (or just 
not install them).


There are arguments for and against removal. IMO non-portability is not 
one of them.


IMHO short tag removal has one major thing going for it, consistency, 
and by extension, predictability.


That's it.

Is that enough? I'm on the fence.

Mark Randall

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello,

On Wed, 7 Aug 2019 at 19:03, Chase Peeler  wrote:
>
>
>
> On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot  wrote:
>>
>> Hello.
>>
>> On Wed, 7 Aug 2019 at 18:56, Chase Peeler  wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot  wrote:
>> >>
>> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski  wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd  
>> >> > wrote:
>> >> >>
>> >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
>> >> >> >
>> >> >> > Yes, last time I was asking this, there was a clarification that
>> >> >> > certain people from the group internals can veto particular RFC.
>> >> >>
>> >> >> Please could you point to where this alleged rule has ever been
>> >> >> written down or agreed to?
>> >> >
>> >> >
>> >> > There's indeed no such rule that any individuals have a veto power.
>> >> >
>> >> >>
>> >> >> Although certain people may have claimed this is a rule, it's never
>> >> >> been agreed afaik.
>> >> >
>> >> >
>> >> > I'm not aware of anybody who ever claimed that such a rule existed, 
>> >> > either.  If people are alluding to me - then I don't claim I can veto 
>> >> > anything;  I think it's also clear from what I think about the short 
>> >> > tags deprecation RFC that if I had veto power, that would be an 
>> >> > instance where I'd use it.  The reason we went for V2 aren't because of 
>> >> > a veto, but because of issues in the previous RFC.
>> >> >
>> >> > With that said - the source code of PHP is copyrighted by the PHP Group 
>> >> > - and it's a fact that is mentioned at the top of every PHP source 
>> >> > file.  The PHP Group is mostly inactive, and will likely stay this way, 
>> >> > but under some extreme situations - it might choose to act (if ever - 
>> >> > probably primarily around things that have to do with process).
>> >> >
>> >> >> I think when we adopt a Code of Conduct one of the things we need to
>> >> >> make explicit is that "claiming authority that is not codified" is
>> >> >> explicitly a thing that will not be allowed in internals discussions
>> >> >> as it seems to keep happening and results in a lot of confusion, and
>> >> >> frustration.
>> >> >
>> >> >
>> >> > The more accurate word here is 'if', rather than 'when'. But I don't 
>> >> > think there's a need to wait for a CoC on this one - it should be clear 
>> >> > that no individual has veto powers, but it should be also clear that 
>> >> > not everything is up for a vote.
>> >> >
>> >> > Zeev
>> >> >
>> >>
>> >> Veto has been mentioned here
>> >> https://externals.io/message/105201#105558
>> >>
>> >> I'm not having any issues with veto being used here or not on a
>> >> previous RFC from people that are in the internals since day 1. I
>> >> think we should respect that they have issues with proposals coming up
>> >> in recent years, but hopefully group will also understand us - users
>> >> and new contributors a bit that we just want to have a bit of cleanup
>> >> of legacy things here and there :)
>> >>
>> >> Thanks and have a nice day.
>> >> --
>> >> Peter Kokot
>> >>
>> >> --
>> >> PHP Internals - PHP Runtime Development Mailing List
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> > What powers are available, and to whom they are available, is probably 
>> > something that should be moved to another thread. We currently have at 
>> > least three different discussions going on in this thread:
>> > 1.) The RFC itself
>> > 2.) Default handling of the ini setting
>> > 3.) Whether certain people can veto RFCs.
>> >
>> > To address Andrey's initial concern, which is currently leading to him not 
>> > voting:
>> >
>> > Nobody is vetoing anything. Due to both the procedural issues (the way the 
>> > voting was structured with two options) as well as the severity of the 
>> > issues raised after the voting, another RFC was proposed that supersedes 
>> > the original RFC. The procedural issues alone were enough to warrant 
>> > another vote on an RFC that had fixed those issues. This means that, for 
>> > all intents and purposes, the first RFC never existed. If the current RFC 
>> > passes, then it will be implemented as proposed. If it fails, then 
>> > treatment of short tags will remain as it currently is.
>> >
>> > I hope you will reconsider your decision to not vote on this new RFC. I 
>> > understand your concerns. As someone that didn't like the outcome of the 
>> > first vote either, I also didn't feel that a revote just because a lot of 
>> > people decided to speak up after the fact was the correct course of 
>> > action. I don't think that is what is happening here, though.
>> >
>> > --
>> > Chase Peeler
>> > chasepee...@gmail.com
>>
>> Just to be more clear here. If the RFC fails then the short opening
>> tags will stay in PHP for ever. I'm not sure what will change in 5 or
>> 10 years so much so considering the feedback I think we should then
>> leave them in for ever and enable them by default everywhere and have
>> two PHP 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Nicolas Grekas]

Le mar. 6 août 2019 à 13:34, G. P. B.  a écrit :

> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> It is expected to last two (2) weeks until 2019-08-20.
>
> A counter argument to this RFC is available at
> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>
> Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2



The counter-arguments are a really nice addition to the process.

Reading them made me think there is a big missing "pro" argument: perceived
complexity of the engine.

When there is no choice to make (short tags on/off, magic_quote on/off,
etc), then there is only one thing to teach, one thing to learn, one thing
to (not have to) agree on when deciding for some conventions, etc.

When there are N binary options (and not all options are binary), there are
2^N things to teach, learn, etc.

That's a major cost put on the community. Choices that were made years ago
when PHP was not what it is today were certainly fine, but nowadays, this
imposes significant a burden on everyone. Each option individually are
maybe minor, but the 2^N becomes quickly big. I think we should make such
things way simpler so that we can free the brains of many to do the next
things that matter.

I don't have a vote, but if I were I would vote "yes". Instead, I encourage
"no"-voters to reconsider, and others to vote "yes" too :)

Cheers,
Nicolas

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot  wrote:

> Hello.
>
> On Wed, 7 Aug 2019 at 18:56, Chase Peeler  wrote:
> >
> >
> >
> > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot 
> wrote:
> >>
> >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski  wrote:
> >> >
> >> >
> >> >
> >> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd 
> wrote:
> >> >>
> >> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot 
> wrote:
> >> >> >
> >> >> > Yes, last time I was asking this, there was a clarification that
> >> >> > certain people from the group internals can veto particular RFC.
> >> >>
> >> >> Please could you point to where this alleged rule has ever been
> >> >> written down or agreed to?
> >> >
> >> >
> >> > There's indeed no such rule that any individuals have a veto power.
> >> >
> >> >>
> >> >> Although certain people may have claimed this is a rule, it's never
> >> >> been agreed afaik.
> >> >
> >> >
> >> > I'm not aware of anybody who ever claimed that such a rule existed,
> either.  If people are alluding to me - then I don't claim I can veto
> anything;  I think it's also clear from what I think about the short tags
> deprecation RFC that if I had veto power, that would be an instance where
> I'd use it.  The reason we went for V2 aren't because of a veto, but
> because of issues in the previous RFC.
> >> >
> >> > With that said - the source code of PHP is copyrighted by the PHP
> Group - and it's a fact that is mentioned at the top of every PHP source
> file.  The PHP Group is mostly inactive, and will likely stay this way, but
> under some extreme situations - it might choose to act (if ever - probably
> primarily around things that have to do with process).
> >> >
> >> >> I think when we adopt a Code of Conduct one of the things we need to
> >> >> make explicit is that "claiming authority that is not codified" is
> >> >> explicitly a thing that will not be allowed in internals discussions
> >> >> as it seems to keep happening and results in a lot of confusion, and
> >> >> frustration.
> >> >
> >> >
> >> > The more accurate word here is 'if', rather than 'when'. But I don't
> think there's a need to wait for a CoC on this one - it should be clear
> that no individual has veto powers, but it should be also clear that not
> everything is up for a vote.
> >> >
> >> > Zeev
> >> >
> >>
> >> Veto has been mentioned here
> >> https://externals.io/message/105201#105558
> >>
> >> I'm not having any issues with veto being used here or not on a
> >> previous RFC from people that are in the internals since day 1. I
> >> think we should respect that they have issues with proposals coming up
> >> in recent years, but hopefully group will also understand us - users
> >> and new contributors a bit that we just want to have a bit of cleanup
> >> of legacy things here and there :)
> >>
> >> Thanks and have a nice day.
> >> --
> >> Peter Kokot
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> > What powers are available, and to whom they are available, is probably
> something that should be moved to another thread. We currently have at
> least three different discussions going on in this thread:
> > 1.) The RFC itself
> > 2.) Default handling of the ini setting
> > 3.) Whether certain people can veto RFCs.
> >
> > To address Andrey's initial concern, which is currently leading to him
> not voting:
> >
> > Nobody is vetoing anything. Due to both the procedural issues (the way
> the voting was structured with two options) as well as the severity of the
> issues raised after the voting, another RFC was proposed that supersedes
> the original RFC. The procedural issues alone were enough to warrant
> another vote on an RFC that had fixed those issues. This means that, for
> all intents and purposes, the first RFC never existed. If the current RFC
> passes, then it will be implemented as proposed. If it fails, then
> treatment of short tags will remain as it currently is.
> >
> > I hope you will reconsider your decision to not vote on this new RFC. I
> understand your concerns. As someone that didn't like the outcome of the
> first vote either, I also didn't feel that a revote just because a lot of
> people decided to speak up after the fact was the correct course of action.
> I don't think that is what is happening here, though.
> >
> > --
> > Chase Peeler
> > chasepee...@gmail.com
>
> Just to be more clear here. If the RFC fails then the short opening
> tags will stay in PHP for ever. I'm not sure what will change in 5 or
> 10 years so much so considering the feedback I think we should then
> leave them in for ever and enable them by default everywhere and have
> two PHP opening tags. Yes, this is what happens when there is no plan
> from key people involved here.
>
> And why is supporting two types of opening tags so bad that it justifies
such a large BC break? Support for short tags has existed since PHP3. Can
you point to anything you've written or used that 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello.

On Wed, 7 Aug 2019 at 18:56, Chase Peeler  wrote:
>
>
>
> On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot  wrote:
>>
>> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski  wrote:
>> >
>> >
>> >
>> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd  wrote:
>> >>
>> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
>> >> >
>> >> > Yes, last time I was asking this, there was a clarification that
>> >> > certain people from the group internals can veto particular RFC.
>> >>
>> >> Please could you point to where this alleged rule has ever been
>> >> written down or agreed to?
>> >
>> >
>> > There's indeed no such rule that any individuals have a veto power.
>> >
>> >>
>> >> Although certain people may have claimed this is a rule, it's never
>> >> been agreed afaik.
>> >
>> >
>> > I'm not aware of anybody who ever claimed that such a rule existed, 
>> > either.  If people are alluding to me - then I don't claim I can veto 
>> > anything;  I think it's also clear from what I think about the short tags 
>> > deprecation RFC that if I had veto power, that would be an instance where 
>> > I'd use it.  The reason we went for V2 aren't because of a veto, but 
>> > because of issues in the previous RFC.
>> >
>> > With that said - the source code of PHP is copyrighted by the PHP Group - 
>> > and it's a fact that is mentioned at the top of every PHP source file.  
>> > The PHP Group is mostly inactive, and will likely stay this way, but under 
>> > some extreme situations - it might choose to act (if ever - probably 
>> > primarily around things that have to do with process).
>> >
>> >> I think when we adopt a Code of Conduct one of the things we need to
>> >> make explicit is that "claiming authority that is not codified" is
>> >> explicitly a thing that will not be allowed in internals discussions
>> >> as it seems to keep happening and results in a lot of confusion, and
>> >> frustration.
>> >
>> >
>> > The more accurate word here is 'if', rather than 'when'. But I don't think 
>> > there's a need to wait for a CoC on this one - it should be clear that no 
>> > individual has veto powers, but it should be also clear that not 
>> > everything is up for a vote.
>> >
>> > Zeev
>> >
>>
>> Veto has been mentioned here
>> https://externals.io/message/105201#105558
>>
>> I'm not having any issues with veto being used here or not on a
>> previous RFC from people that are in the internals since day 1. I
>> think we should respect that they have issues with proposals coming up
>> in recent years, but hopefully group will also understand us - users
>> and new contributors a bit that we just want to have a bit of cleanup
>> of legacy things here and there :)
>>
>> Thanks and have a nice day.
>> --
>> Peter Kokot
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
> What powers are available, and to whom they are available, is probably 
> something that should be moved to another thread. We currently have at least 
> three different discussions going on in this thread:
> 1.) The RFC itself
> 2.) Default handling of the ini setting
> 3.) Whether certain people can veto RFCs.
>
> To address Andrey's initial concern, which is currently leading to him not 
> voting:
>
> Nobody is vetoing anything. Due to both the procedural issues (the way the 
> voting was structured with two options) as well as the severity of the issues 
> raised after the voting, another RFC was proposed that supersedes the 
> original RFC. The procedural issues alone were enough to warrant another vote 
> on an RFC that had fixed those issues. This means that, for all intents and 
> purposes, the first RFC never existed. If the current RFC passes, then it 
> will be implemented as proposed. If it fails, then treatment of short tags 
> will remain as it currently is.
>
> I hope you will reconsider your decision to not vote on this new RFC. I 
> understand your concerns. As someone that didn't like the outcome of the 
> first vote either, I also didn't feel that a revote just because a lot of 
> people decided to speak up after the fact was the correct course of action. I 
> don't think that is what is happening here, though.
>
> --
> Chase Peeler
> chasepee...@gmail.com

Just to be more clear here. If the RFC fails then the short opening
tags will stay in PHP for ever. I'm not sure what will change in 5 or
10 years so much so considering the feedback I think we should then
leave them in for ever and enable them by default everywhere and have
two PHP opening tags. Yes, this is what happens when there is no plan
from key people involved here.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot  wrote:

> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski  wrote:
> >
> >
> >
> > On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd 
> wrote:
> >>
> >> On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
> >> >
> >> > Yes, last time I was asking this, there was a clarification that
> >> > certain people from the group internals can veto particular RFC.
> >>
> >> Please could you point to where this alleged rule has ever been
> >> written down or agreed to?
> >
> >
> > There's indeed no such rule that any individuals have a veto power.
> >
> >>
> >> Although certain people may have claimed this is a rule, it's never
> >> been agreed afaik.
> >
> >
> > I'm not aware of anybody who ever claimed that such a rule existed,
> either.  If people are alluding to me - then I don't claim I can veto
> anything;  I think it's also clear from what I think about the short tags
> deprecation RFC that if I had veto power, that would be an instance where
> I'd use it.  The reason we went for V2 aren't because of a veto, but
> because of issues in the previous RFC.
> >
> > With that said - the source code of PHP is copyrighted by the PHP Group
> - and it's a fact that is mentioned at the top of every PHP source file.
> The PHP Group is mostly inactive, and will likely stay this way, but under
> some extreme situations - it might choose to act (if ever - probably
> primarily around things that have to do with process).
> >
> >> I think when we adopt a Code of Conduct one of the things we need to
> >> make explicit is that "claiming authority that is not codified" is
> >> explicitly a thing that will not be allowed in internals discussions
> >> as it seems to keep happening and results in a lot of confusion, and
> >> frustration.
> >
> >
> > The more accurate word here is 'if', rather than 'when'. But I don't
> think there's a need to wait for a CoC on this one - it should be clear
> that no individual has veto powers, but it should be also clear that not
> everything is up for a vote.
> >
> > Zeev
> >
>
> Veto has been mentioned here
> https://externals.io/message/105201#105558
>
> I'm not having any issues with veto being used here or not on a
> previous RFC from people that are in the internals since day 1. I
> think we should respect that they have issues with proposals coming up
> in recent years, but hopefully group will also understand us - users
> and new contributors a bit that we just want to have a bit of cleanup
> of legacy things here and there :)
>
> Thanks and have a nice day.
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> What powers are available, and to whom they are available, is probably
something that should be moved to another thread. We currently have at
least three different discussions going on in this thread:
1.) The RFC itself
2.) Default handling of the ini setting
3.) Whether certain people can veto RFCs.

To address Andrey's initial concern, which is currently leading to him not
voting:

Nobody is vetoing anything. Due to both the procedural issues (the way the
voting was structured with two options) as well as the severity of the
issues raised after the voting, another RFC was proposed that supersedes
the original RFC. The procedural issues alone were enough to warrant
another vote on an RFC that had fixed those issues. This means that, for
all intents and purposes, the first RFC never existed. If the current RFC
passes, then it will be implemented as proposed. If it fails, then
treatment of short tags will remain as it currently is.

I hope you will reconsider your decision to not vote on this new RFC. I
understand your concerns. As someone that didn't like the outcome of the
first vote either, I also didn't feel that a revote just because a lot of
people decided to speak up after the fact was the correct course of action.
I don't think that is what is happening here, though.

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Wed, 7 Aug 2019 at 16:14, Zeev Suraski  wrote:
>
>
>
> On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd  wrote:
>>
>> On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
>> >
>> > Yes, last time I was asking this, there was a clarification that
>> > certain people from the group internals can veto particular RFC.
>>
>> Please could you point to where this alleged rule has ever been
>> written down or agreed to?
>
>
> There's indeed no such rule that any individuals have a veto power.
>
>>
>> Although certain people may have claimed this is a rule, it's never
>> been agreed afaik.
>
>
> I'm not aware of anybody who ever claimed that such a rule existed, either.  
> If people are alluding to me - then I don't claim I can veto anything;  I 
> think it's also clear from what I think about the short tags deprecation RFC 
> that if I had veto power, that would be an instance where I'd use it.  The 
> reason we went for V2 aren't because of a veto, but because of issues in the 
> previous RFC.
>
> With that said - the source code of PHP is copyrighted by the PHP Group - and 
> it's a fact that is mentioned at the top of every PHP source file.  The PHP 
> Group is mostly inactive, and will likely stay this way, but under some 
> extreme situations - it might choose to act (if ever - probably primarily 
> around things that have to do with process).
>
>> I think when we adopt a Code of Conduct one of the things we need to
>> make explicit is that "claiming authority that is not codified" is
>> explicitly a thing that will not be allowed in internals discussions
>> as it seems to keep happening and results in a lot of confusion, and
>> frustration.
>
>
> The more accurate word here is 'if', rather than 'when'. But I don't think 
> there's a need to wait for a CoC on this one - it should be clear that no 
> individual has veto powers, but it should be also clear that not everything 
> is up for a vote.
>
> Zeev
>

Veto has been mentioned here
https://externals.io/message/105201#105558

I'm not having any issues with veto being used here or not on a
previous RFC from people that are in the internals since day 1. I
think we should respect that they have issues with proposals coming up
in recent years, but hopefully group will also understand us - users
and new contributors a bit that we just want to have a bit of cleanup
of legacy things here and there :)

Thanks and have a nice day.
-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Ben Ramsey]

> On Aug 7, 2019, at 09:09, Ben Ramsey  wrote:
> 
>> On Aug 7, 2019, at 09:03, Peter Bowyer  wrote:
>> 
>> On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd  wrote:
>> 
>>> I think when we adopt a Code of Conduct one of the things we need to
>>> make explicit is that "claiming authority that is not codified" is
>>> explicitly a thing that will not be allowed in internals discussions
>>> as it seems to keep happening and results in a lot of confusion, and
>>> frustration.
>>> 
>> 
>> Documenting the project structure would also be helpful.
>> 
>> When the PHP Group was mentioned I went hunting for details. I found a list
>> of names at the top of https://www.php.net/credits.php but nothing covering
>> what their role or authority is.
> 
> 
> Their “role and authority” is copyright ownership of the “code, text, PHP 
> logo, and graphical elements” of the PHP website. 
> https://www.php.net/copyright.php


Clarification: I didn’t mean to imply just the PHP website. I meant the entire 
part of the PHP code base that is covered by the PHP license. 
https://github.com/php/php-src/blob/master/LICENSE

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Zeev Suraski]

On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd  wrote:

> On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
> >
> > Yes, last time I was asking this, there was a clarification that
> > certain people from the group internals can veto particular RFC.
>
> Please could you point to where this alleged rule has ever been
> written down or agreed to?
>

There's indeed no such rule that any individuals have a veto power.


> Although certain people may have claimed this is a rule, it's never
> been agreed afaik.
>

I'm not aware of anybody who ever claimed that such a rule existed,
either.  If people are alluding to me - then I don't claim I can veto
anything;  I think it's also clear from what I think about the short tags
deprecation RFC that *if* I had veto power, that would be an instance where
I'd use it.  The reason we went for V2 aren't because of a veto, but
because of issues in the previous RFC.

With that said - the source code of PHP is copyrighted by the PHP Group -
and it's a fact that is mentioned at the top of every PHP source file.  The
PHP Group is mostly inactive, and will likely stay this way, but under some
extreme situations - it might choose to act (if ever - probably primarily
around things that have to do with process).

I think when we adopt a Code of Conduct one of the things we need to
> make explicit is that "claiming authority that is not codified" is
> explicitly a thing that will not be allowed in internals discussions
> as it seems to keep happening and results in a lot of confusion, and
> frustration.
>

The more accurate word here is 'if', rather than 'when'. But I don't think
there's a need to wait for a CoC on this one - it should be clear that no
individual has veto powers, but it should be also clear that not everything
is up for a vote.

Zeev

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Ben Ramsey]

> On Aug 7, 2019, at 09:03, Peter Bowyer  wrote:
> 
> On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd  wrote:
> 
>> I think when we adopt a Code of Conduct one of the things we need to
>> make explicit is that "claiming authority that is not codified" is
>> explicitly a thing that will not be allowed in internals discussions
>> as it seems to keep happening and results in a lot of confusion, and
>> frustration.
>> 
> 
> Documenting the project structure would also be helpful.
> 
> When the PHP Group was mentioned I went hunting for details. I found a list
> of names at the top of https://www.php.net/credits.php but nothing covering
> what their role or authority is.


Their “role and authority” is copyright ownership of the “code, text, PHP logo, 
and graphical elements” of the PHP website. https://www.php.net/copyright.php

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Bowyer]

On Wed, 7 Aug 2019 at 14:56, Dan Ackroyd  wrote:

> I think when we adopt a Code of Conduct one of the things we need to
> make explicit is that "claiming authority that is not codified" is
> explicitly a thing that will not be allowed in internals discussions
> as it seems to keep happening and results in a lot of confusion, and
> frustration.
>

Documenting the project structure would also be helpful.

When the PHP Group was mentioned I went hunting for details. I found a list
of names at the top of https://www.php.net/credits.php but nothing covering
what their role or authority is.

Peter

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Dan Ackroyd]

On Wed, 7 Aug 2019 at 09:45, Peter Kokot  wrote:
>
> Yes, last time I was asking this, there was a clarification that
> certain people from the group internals can veto particular RFC.

Please could you point to where this alleged rule has ever been
written down or agreed to?

Although certain people may have claimed this is a rule, it's never
been agreed afaik.

I think when we adopt a Code of Conduct one of the things we need to
make explicit is that "claiming authority that is not codified" is
explicitly a thing that will not be allowed in internals discussions
as it seems to keep happening and results in a lot of confusion, and
frustration.

cheers
Dan
Ack

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Collins]

On 07/08/2019 09:11, Nikita Popov wrote:

To clarify: What I had in mind is that use of  in PHP code requires an explicit short_tags=Off right now, so the
situation there shouldn't change, unless I'm missing something.



Since it would behave differently, it wouldn't make sense to say that it 
defaulted to "On", but that actually leads to an interesting feature: 
add an "error" mode to that setting. So the options would be:


- error: any use of "error; compile-time default
- off: "by most packages

- on: "We could either leave the recommended ini setting in the official 
distribution as "off" (more compatible) or set it to "error" (to make 
mistakes safer and easier to spot).


Regards.

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Zeev Suraski]

On 7 Aug 2019, at 12:39, Christoph M. Becker 
mailto:cmbecke...@gmx.de>> wrote:

As I understand it, this RFC has been put to vote again, because the first 
version had some problematic details, and by courtesy to cater to the clamor 
raised after
the voting had finished.

That is correct.  There was an inconsistency with the Voting RFC in the voting 
options, and the RFC (as it passed) also had catastrophic implications for 
upgrades - so it could not be implemented as it was written.

Zeev

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Christoph M. Becker]

On 07.08.2019 at 10:44, Peter Kokot wrote:

> On Wed, 7 Aug 2019 at 09:28, Andrey Andreev  wrote:
>
>> On Tue, Aug 6, 2019 at 8:20 PM G. P. B.  wrote:
>>
>>> This RFC supersedes the previous one as stated in the the RFC itself : "
>>> This RFC supersedes the previous one and proposes a different deprecation
>>> approach." meaning that the previous one is void.
>>> I don't know why this is ambiguous and needs to be said once again.
>>
>> As far as I know, there's been no vote to cancel the previously
>> accepted RFC, so ... even though I didn't like the outcome of it, I
>> don't understand how it is just made void now. It's pretty easy to
>> understand the ambiguity.
>>
>> I won't be voting on this one due to all of this.
>
> Yes, last time I was asking this, there was a clarification that
> certain people from the group internals can veto particular RFC. So, I
> think that this is the case here.

I'm not aware of *any* veto rights regarding RFCs.  As I understand it,
this RFC has been put to vote again, because the first version had some
problematic details, and by courtesy to cater to the clamor raised after
the voting had finished.

Thanks,
Christoph

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello,

On Wed, 7 Aug 2019 at 09:28, Andrey Andreev  wrote:
>
> Hi,
>
> On Tue, Aug 6, 2019 at 8:20 PM G. P. B.  wrote:
> >
> > This RFC supersedes the previous one as stated in the the RFC itself : "
> > This RFC supersedes the previous one and proposes a different deprecation
> > approach." meaning that the previous one is void.
> > I don't know why this is ambiguous and needs to be said once again.
> >
>
> As far as I know, there's been no vote to cancel the previously
> accepted RFC, so ... even though I didn't like the outcome of it, I
> don't understand how it is just made void now. It's pretty easy to
> understand the ambiguity.
>
> I won't be voting on this one due to all of this.
>
> Cheers,
> Andrey.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Yes, last time I was asking this, there was a clarification that
certain people from the group internals can veto particular RFC. So, I
think that this is the case here.

-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Nikita Popov]

On Tue, Aug 6, 2019 at 11:55 PM Claude Pache  wrote:

>
>
> > Le 6 août 2019 à 20:46, Nikita Popov  a écrit :
> >
> > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. 
> wrote:
> >
> >> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> >> It is expected to last two (2) weeks until 2019-08-20.
> >>
> >> A counter argument to this RFC is available at
> >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> >>
> >> Best regards
> >>
> >> George P. Banyard
> >>
> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
> >>
> >
> > Side-note: Even if this RFC fails, we should probably still make it an
> > error to use  we
> > may flip the default to off at some later point in time. The current
> > default being "on" despite their use being discouraged is half the
> trouble.
> >
> > Nikita
>
>
> That would mean in particular that XML documents could no longer be
> preprocessed by PHP without boilerplate around its `` declaration.
> I doubt that this is a more acceptable breaking change than deprecating
> short_tags.


To clarify: What I had in mind is that use of  in PHP code requires an explicit short_tags=Off right now, so the
situation there shouldn't change, unless I'm missing something.

The only motivation here is to allow us to change the default to
short_tags=Off at some point in the future (say PHP 9), after enough time
has passed where short_tags cannot be used by default, without explicitly
being enabled. We can't just flip the default right now due to the usual
code leaking concerns.

Regards,
Nikita

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Andrey Andreev]

Hi,

On Tue, Aug 6, 2019 at 8:20 PM G. P. B.  wrote:
>
> This RFC supersedes the previous one as stated in the the RFC itself : "
> This RFC supersedes the previous one and proposes a different deprecation
> approach." meaning that the previous one is void.
> I don't know why this is ambiguous and needs to be said once again.
>

As far as I know, there's been no vote to cancel the previously
accepted RFC, so ... even though I didn't like the outcome of it, I
don't understand how it is just made void now. It's pretty easy to
understand the ambiguity.

I won't be voting on this one due to all of this.

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Walter Parker]

On Tue, Aug 6, 2019 at 2:55 PM Claude Pache  wrote:

>
>
> > Le 6 août 2019 à 20:46, Nikita Popov  a écrit :
> >
> > On Tue, Aug 6, 2019 at 1:34 PM G. P. B. 
> wrote:
> >
> >> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> >> It is expected to last two (2) weeks until 2019-08-20.
> >>
> >> A counter argument to this RFC is available at
> >> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
> >>
> >> Best regards
> >>
> >> George P. Banyard
> >>
> >> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
> >>
> >
> > Side-note: Even if this RFC fails, we should probably still make it an
> > error to use  we
> > may flip the default to off at some later point in time. The current
> > default being "on" despite their use being discouraged is half the
> trouble.
> >
> > Nikita
>
>
> That would mean in particular that XML documents could no longer be
> preprocessed by PHP without boilerplate around its `` declaration.
> I doubt that this is a more acceptable breaking change than deprecating
> short_tags.
>
> —Claude
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Why would you want to use PHP's preprocessor for XML?
Why not use the right tool for the job? Such as an XML processor that could
also do schema validation? PHP has XML processing packages. It has been a
while since I did XML processing, but I don't remember the packages being
all that difficult to use. Is this a mixing data and code into the same
file problem? Like HTML files that have PHP embedded directly in the file?
Or this about stuffing PHP inside of XML documents?


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Claude Pache]

> Le 6 août 2019 à 20:46, Nikita Popov  a écrit :
> 
> On Tue, Aug 6, 2019 at 1:34 PM G. P. B.  wrote:
> 
>> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
>> It is expected to last two (2) weeks until 2019-08-20.
>> 
>> A counter argument to this RFC is available at
>> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>> 
>> Best regards
>> 
>> George P. Banyard
>> 
>> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>> 
> 
> Side-note: Even if this RFC fails, we should probably still make it an
> error to use  may flip the default to off at some later point in time. The current
> default being "on" despite their use being discouraged is half the trouble.
> 
> Nikita


That would mean in particular that XML documents could no longer be 
preprocessed by PHP without boilerplate around its `` declaration. I 
doubt that this is a more acceptable breaking change than deprecating 
short_tags.

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Zeev Suraski]

> On 6 Aug 2019, at 21:46, Nikita Popov  wrote:
> 
>> On Tue, Aug 6, 2019 at 1:34 PM G. P. B.  wrote:
>> 
>> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
>> It is expected to last two (2) weeks until 2019-08-20.
>> 
>> A counter argument to this RFC is available at
>> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>> 
>> Best regards
>> 
>> George P. Banyard
>> 
>> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>> 
> 
> Side-note: Even if this RFC fails, we should probably still make it an
> error to use  may flip the default to off at some later point in time. The current
> default being "on" despite their use being discouraged is half the trouble.
> 

That’s a good idea.  I was genuinely surprised to learn that wasn’t already the 
case, although the actual impact of that is quite limited given the fact that 
virtually all common deployments come preconfigured with short tags set to off.

Zeev

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Nikita Popov]

On Tue, Aug 6, 2019 at 1:34 PM G. P. B.  wrote:

> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> It is expected to last two (2) weeks until 2019-08-20.
>
> A counter argument to this RFC is available at
> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>
> Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>

Side-note: Even if this RFC fails, we should probably still make it an
error to use 

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[G. P. B.]

On Tue, 6 Aug 2019 at 19:25, Chase Peeler  wrote:

>
>
> On Tue, Aug 6, 2019 at 1:19 PM G. P. B.  wrote:
>
>>
>>
>>
>> On Tue, 6 Aug 2019 at 19:12, Rowan Collins 
>> wrote:
>>
>>> On Tue, 6 Aug 2019 at 17:59, Chase Peeler  wrote:
>>>
>>> > I'm not a voter, but, I have a question. If this fails, does that mean
>>> the
>>> > original RFC that passed is still in effect?
>>> >
>>>
>>>
>>> Yes, this is really ambiguous, and risks the situation being even more
>>> confusing than it was before.
>>>
>>> The "No" column on this RFC already includes people who voted "Yes" on
>>> the
>>> previous version; is this an indication that they have changed their mind
>>> about removing short tags, or that they prefer the original proposal?
>>>
>>> I think we urgently need to clarify this, and may need to reset the vote
>>> with one or more clearer questions.
>>>
>>> Regards,
>>> --
>>> Rowan Collins
>>> [IMSoP]
>>
>>
>> This RFC supersedes the previous one as stated in the the RFC itself : "
>> This RFC supersedes the previous one and proposes a different
>> deprecation approach." meaning that the previous one is void.
>> I don't know why this is ambiguous and needs to be said once again.
>>
>> Just to clarify - the existence of this RFC effectively means the
> original never existed.
>
>
>> Best regards
>>
>> George P. Banyard
>>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

In a sense yes, however this RFC is a vote on the implementation which
would have landed with the previous one but was not the one voted.
So you can disregard the result of the previous one not the controversial
discussion it generated after the vote was accepted.

Hope this clarifies everything.

Best regards

George P. Banyard

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Tue, Aug 6, 2019 at 1:19 PM G. P. B.  wrote:

>
>
>
> On Tue, 6 Aug 2019 at 19:12, Rowan Collins 
> wrote:
>
>> On Tue, 6 Aug 2019 at 17:59, Chase Peeler  wrote:
>>
>> > I'm not a voter, but, I have a question. If this fails, does that mean
>> the
>> > original RFC that passed is still in effect?
>> >
>>
>>
>> Yes, this is really ambiguous, and risks the situation being even more
>> confusing than it was before.
>>
>> The "No" column on this RFC already includes people who voted "Yes" on the
>> previous version; is this an indication that they have changed their mind
>> about removing short tags, or that they prefer the original proposal?
>>
>> I think we urgently need to clarify this, and may need to reset the vote
>> with one or more clearer questions.
>>
>> Regards,
>> --
>> Rowan Collins
>> [IMSoP]
>
>
> This RFC supersedes the previous one as stated in the the RFC itself : "
> This RFC supersedes the previous one and proposes a different deprecation
> approach." meaning that the previous one is void.
> I don't know why this is ambiguous and needs to be said once again.
>
> Just to clarify - the existence of this RFC effectively means the original
never existed.


> Best regards
>
> George P. Banyard
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

Hello,

On Tue, 6 Aug 2019 at 19:19, G. P. B.  wrote:
>
> On Tue, 6 Aug 2019 at 19:12, Rowan Collins  wrote:
>
> > On Tue, 6 Aug 2019 at 17:59, Chase Peeler  wrote:
> >
> > > I'm not a voter, but, I have a question. If this fails, does that mean
> > the
> > > original RFC that passed is still in effect?
> > >
> >
> >
> > Yes, this is really ambiguous, and risks the situation being even more
> > confusing than it was before.
> >
> > The "No" column on this RFC already includes people who voted "Yes" on the
> > previous version; is this an indication that they have changed their mind
> > about removing short tags, or that they prefer the original proposal?
> >
> > I think we urgently need to clarify this, and may need to reset the vote
> > with one or more clearer questions.
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
>
>
> This RFC supersedes the previous one as stated in the the RFC itself : "
> This RFC supersedes the previous one and proposes a different deprecation
> approach." meaning that the previous one is void.
> I don't know why this is ambiguous and needs to be said once again.
>
> Best regards
>
> George P. Banyard


Thank you for clarification. From what I understand it is the case
where "no" means a status quo and no agreements has been reached on
the original RFC. Since the original RFC has been vetoed and so much
energy was invested from Zeev and some others commentators then I
guess the RFCs fail and we will have two types of opening tags in PHP
for ever. Otherwise, as described, yes.



-- 
Peter Kokot

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[G. P. B.]

On Tue, 6 Aug 2019 at 19:12, Rowan Collins  wrote:

> On Tue, 6 Aug 2019 at 17:59, Chase Peeler  wrote:
>
> > I'm not a voter, but, I have a question. If this fails, does that mean
> the
> > original RFC that passed is still in effect?
> >
>
>
> Yes, this is really ambiguous, and risks the situation being even more
> confusing than it was before.
>
> The "No" column on this RFC already includes people who voted "Yes" on the
> previous version; is this an indication that they have changed their mind
> about removing short tags, or that they prefer the original proposal?
>
> I think we urgently need to clarify this, and may need to reset the vote
> with one or more clearer questions.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]


This RFC supersedes the previous one as stated in the the RFC itself : "
This RFC supersedes the previous one and proposes a different deprecation
approach." meaning that the previous one is void.
I don't know why this is ambiguous and needs to be said once again.

Best regards

George P. Banyard

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Collins]

On Tue, 6 Aug 2019 at 17:59, Chase Peeler  wrote:

> I'm not a voter, but, I have a question. If this fails, does that mean the
> original RFC that passed is still in effect?
>


Yes, this is really ambiguous, and risks the situation being even more
confusing than it was before.

The "No" column on this RFC already includes people who voted "Yes" on the
previous version; is this an indication that they have changed their mind
about removing short tags, or that they prefer the original proposal?

I think we urgently need to clarify this, and may need to reset the vote
with one or more clearer questions.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

I'm not a voter, but, I have a question. If this fails, does that mean the
original RFC that passed is still in effect?

If I did have a vote, I would be against this RFC for the reasons laid out
by Zeev in the counter argument. However, I feel the negative impacts of
possible code leaks that will be caused by the original RFC are even worse.
If I did have a vote, I might feel forced to vote for this. At least with
this RFC we wouldn't really see any of the other negative impacts until PHP
9, given us time to revisit and possibly reverse that part of this RFC.

On Tue, Aug 6, 2019 at 7:34 AM G. P. B.  wrote:

> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> It is expected to last two (2) weeks until 2019-08-20.
>
> A counter argument to this RFC is available at
> https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags
>
> Best regards
>
> George P. Banyard
>
> [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2
>


-- 
Chase Peeler
chasepee...@gmail.com