Re: [PHP-DEV] [RFC] Allow throwing exceptions from __toString()

[Bishop Bettini]

On Tue, Apr 30, 2019 at 2:49 PM Stanislav Malyshev 
wrote:

>
> That said, the work done on the patch is super impressive. I am
> reasonably sure that Nikita caught as many instances of something going
> wrong when string conversion fails as humanly possible. And I agree that
> banning exceptions didn't actually solve the problem anyway, because
> error handlers present the same exactly issue - exceptions are just much
> more prominent and immediate in their effects, but with some hostile
> coding - or even some inadvertently convoluted one - you'd run into the
> same issues again. Some extensions will probably have some trouble -
> though with high likelyhood they already do anyway.


I second that "super impressive work". I'm certain some of why it's been
deferred is because doing it was, well, unpleasant. Thanks Nikita for
wrestling this.

I spent an hour today going through the patch, especially its effect on the
phar and imap extensions, and Zend/*. The patch seems good to me, minus a
few targeted comments. But I'd still think this would be a "many eyes
needed" kind of PR, especially from extension maintainers.

+1 from me.

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

[Mark Randall]

On 01/05/2019 01:19, Peter Kokot wrote:

I haven't seen code with short tags for such a long time now that this
is for me a problem on a scale of a fly. Because we've simply upgraded
all very very long time ago or in other words even never thought of
writing something in these tags anymore. 


I think it's important to remember that for every piece of actual code 
that's seen in the wild on the internet, there's likely a couple of 
orders of magnitude more that never leaves the proprietary servers / 
repositories of individual companies -- Code that has been written over 
a great many years that could always rely on short open tags being there 
 because it's company code on company servers running php.inis 
configured by company staff.


The code exposure is secondary IMO. I mean, it's certainly bad, but 
developers will be faced with a much more catastrophic issue to contend 
with, and that's the somewhat terrifying issue of logical control 
operations silently ceasing to exist.



Super Secret: 


If people are so adamant about getting rid of it (as opposed to just 
making it always available) then I think Nikita needs to bring forward 
his proposals as an RFC with all due haste, as it's quite clear the 
current plan cannot go forward as-is.


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

[Peter Kokot]

On Wed, 1 May 2019 at 00:56, Stanislav Malyshev  wrote:
>
> Hi!
>
> > Worth noting another inconsistency here that we've missed. PHP 7.4 has
> > introduced many BC breaks actually already. Without this level of
> > problems:
>
> Exactly, without. There's a difference between removing an unmaintained
> extension which is barely used and setting people up for displaying
> their sources if they use slightly outdated libraries. And there's a
> difference between explicitly making a decision and not even bothering
> to discuss this mammoth of a BC break until the vote is finished. So to
> me it's more like "elephant in the room" scenario - we've got a process
> failure here. We are on the course to correct it, but it's a failure
> nevertheless.

It is a BC break nevertheless no matter how much time it takes to
change the code. The level of the impact cannot be measured like this.
Every app will have different things to fix. So saying that this
particular change will break the internet is not realistic without any
numbers. If PHP is on a course to fix the BC break strategy then good
(for example, BC breaks allowed in major releases, minor releases
including only new features etc). Upgrading PHP version would be then
a breeze probably but very complex to maintain the code in the repo
(at least according to the release cycles of 5+ years to get to a
major version). However, I'm not sure I'm seeing such direction or
anyone expressing it to do this at least according to many here and
even this discussion. Because, from what I think here more is that
we're discussing how to keep the short tags forever and how to remove
them as soon as possible. There is a difference in what people want
here. And majority of those not in favour of the removal in PHP 8,
want them to have forever and basically want to change the issue of
removing the tags in the first place. I haven't seen any step forward
from this point yet and what kind of a different removal strategy
(compared to Nikita's suggestion) would work.

> > The deprecation in PHP 7.4 (or even if there wouldn't be any
> > deprecation here at all) and removal of some short tags in PHP 8 is
> > the least of users problems I think.
>
> You mean wddx removal is much bigger problem for users than the
> potential for their code to be sent out instead of executed? If so, we
> must be living in very different words, because for me the former is a
> blip on the margin of the radar and the latter is a "world on fire, do
> not upgrade under any circumstances" scenario. I could easily ignore the
> former and I wouldn't dare to upgrade any production for the latter
> without long process of verification that would 100% ensure there's no
> bad tags hiding in any code, any dependency, any library, etc. Maybe
> it's what the RFC authors want, but it's certainly a giant difference in
> BC impact.

I haven't seen code with short tags for such a long time now that this
is for me a problem on a scale of a fly. Because we've simply upgraded
all very very long time ago or in other words even never thought of
writing something in these tags anymore. Well, obviously this might be
for someone else a problem on a scale of an elephant, that I don't
know and probably won't understand fully. But, also at least now this
discussion and also RFC brought this thing out - short open tags
shouldn't be used anymore in any case. :) Because obviously a very
large number of people would like to have more clear definition of
what is opening PHP tag.

-- 
Peter Kokot

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

Re: [PHP-DEV] Revive Number Format Separator RFC

[Bishop Bettini]

On Tue, Apr 30, 2019, 19:14 Theodore Brown  On Tue, Apr 30, 2019 at 3:59 PM Bishop Bettini  wrote:
>
> > Excellent. I hope we can make the case this time. Please
> > request Wiki karma [1], and we'll iterate on it there.
>
> I was granted karma, and published an initial RFC draft:
> https://wiki.php.net/rfc/numeric_literal_separator.
>
> I would greatly appreciate help with the implementation, since I
> don't have much experience with C and haven't contributed to PHP before.
>
> Also let me know if you have any ideas for improving the RFC.
>

I am happy to help with these. Let us take the RFC refinement and
implementation details conversation off-list. Then come back when prepared
to present for discussion.

>

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

[Stanislav Malyshev]

Hi!

> Worth noting another inconsistency here that we've missed. PHP 7.4 has
> introduced many BC breaks actually already. Without this level of
> problems:

Exactly, without. There's a difference between removing an unmaintained
extension which is barely used and setting people up for displaying
their sources if they use slightly outdated libraries. And there's a
difference between explicitly making a decision and not even bothering
to discuss this mammoth of a BC break until the vote is finished. So to
me it's more like "elephant in the room" scenario - we've got a process
failure here. We are on the course to correct it, but it's a failure
nevertheless.

> The deprecation in PHP 7.4 (or even if there wouldn't be any
> deprecation here at all) and removal of some short tags in PHP 8 is
> the least of users problems I think.

You mean wddx removal is much bigger problem for users than the
potential for their code to be sent out instead of executed? If so, we
must be living in very different words, because for me the former is a
blip on the margin of the radar and the latter is a "world on fire, do
not upgrade under any circumstances" scenario. I could easily ignore the
former and I wouldn't dare to upgrade any production for the latter
without long process of verification that would 100% ensure there's no
bad tags hiding in any code, any dependency, any library, etc. Maybe
it's what the RFC authors want, but it's certainly a giant difference in
BC impact.

> Without these kind of "hacks" PHP wouldn't even move forward anymore.
> Contributing to it would be in most cases only maintenance, fixing
> bugs and compatibility with platforms out there. So nothing exciting

There's a lot to do in PHP without breaking things. How much time you've
got?
-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Re: Wiki RFC karma request

[Christoph M. Becker]

On 30.04.2019 at 23:51, Theodore Brown wrote:

> Hi, I'd like to resurrect the RFC for underscore separators in numeric 
> literals. Could someone grant me the necessary wiki karma? My username is 
> theodorejb.

You should have rfc karma.  Best of luck with the RFC!

--
Christoph M. Becker

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

[PHP-DEV] Wiki RFC karma request

[Theodore Brown]

Hi, I'd like to resurrect the RFC for underscore separators in numeric 
literals. Could someone grant me the necessary wiki karma? My username is 
theodorejb.

Thanks,

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

Re: [PHP-DEV] Revive Number Format Separator RFC

[Bishop Bettini]

On Tue, Apr 30, 2019 at 4:41 PM Theodore Brown 
wrote:

> On Mon, Apr 29, 2019 at 2:33 AM Bishop Bettini  wrote:
>
> > Well said.
> >
> > One need not agree with an implementation to appreciate the improved
> > readability.
> >
> > If you'd like to re-open this for voting, I'm able to assist with
> > the RFC process and any code changes.
>
> Thanks! I drafted a preliminary RFC, but I'll need assistance with
> the implementation and publishing the RFC on wiki.php.net.
>
> https://gist.github.com/theodorejb/653221e3221b2b4d2ad8fa94d3a963ff


Excellent. I hope we can make the case this time. Please request Wiki karma
[1], and we'll iterate on it there.

[1]: https://wiki.php.net/rfc/howto

Re: [PHP-DEV] Revive Number Format Separator RFC

[Theodore Brown]

On Mon, Apr 29, 2019 at 2:33 AM Bishop Bettini  wrote:

> Well said.
>
> One need not agree with an implementation to appreciate the improved
> readability.
>
> If you'd like to re-open this for voting, I'm able to assist with
> the RFC process and any code changes.

Thanks! I drafted a preliminary RFC, but I'll need assistance with
the implementation and publishing the RFC on wiki.php.net.

https://gist.github.com/theodorejb/653221e3221b2b4d2ad8fa94d3a963ff

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

[Bishop Bettini]

On Wed, Apr 24, 2019 at 8:19 PM Michael Kliewe  wrote:

> Some random thoughts:
> - What happens to .phar files? Do we have to scan the contents?
>

Phar relies upon the engine's tokenizer. If your phar build script uses createDefaultStub('index.php');
$phar->setStub($stub);

$ php -d phar.readonly=Off create-test.phar.php

$ php -d short_open_tag=On test.phar
I am a short tag

$ php -d short_open_tag=Off test.phar

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

[Peter Kokot]

Hello,

On Tue, 30 Apr 2019 at 20:25, Zeev Suraski  wrote:
>
> On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans  wrote:
>
> > On Mon, 29 Apr 2019, Zeev Suraski wrote:
> >
> > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. 
> > wrote:
> > >
> > > > I think this just boils down to what is an acceptable majority, if
> > > > 2/3 is not enough then 3/4 but this is another debate altogether.
> > > >
> > >
> > > I've argued in the past that it would make sense to require a 9/10
> > majority
> > > for RFCs.  Very few RFCs that passed - only cleared a 2/3 majority.
> > > Usually (in the vast majority of cases), it either clears a nearly
> > > unanimous vote - or it doesn't even come close to 2/3.
> > >
> > > RFCs that have a high number of votes (i.e., that people feel strongly
> > > about), and barely pass the 2/3 mark - are controversial and saw
> > division.
> > > Yes, it means that out of the (almost random) group of people who are
> > > currently enabled to vote by our (flawed) voting system
> >
> > If you think it's flawed
>
>
> It's not that I think it's flawed - I know it's flawed.  It doesn't
> implement what was agreed upon when the Voting RFC was enacted.
>
>
> > , you know that the RFC process is there for
> > anybody to change it. Joe already managed twice towards what you
> > suggested in your stalled RFC:
> >
> > - https://wiki.php.net/rfc/abolish-short-votes
> > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
> >   against this one to raise the barrier from 50%+1 to ⅔rds).
> >
>
> I'm well aware of it.  In doing that, I think we greatly complicated the
> prospects of fixing the voting eligibility - which is an infinitely hotter
> potato to handle. Both 'abolish' RFCs enjoyed popular support and had very
> little touchy subjects - unlike the topic of who gets to vote, or the
> prospect of moving to a consensus-based system.
>
> > It's absolutely fine to dislike short tags.  It's absolutely fine to
> > > believe it shouldn't have been introduced.  But the gap between that,
> > > and thinking it's fine to remove it - is very, very big.
> >
> > But the fact is that the RFC passed. And retroactively changing rules
> > because somebody don't agree with a decision is making a farce out of
> > the process.
> >
>
> I've detailed the issues with the RFC in my other reply.
>
> I'm well aware that I'm spending quite a bit of 'credit capital' by
> weighing in on this, and I'm enjoying it roughly as one would enjoy having
> their tooth pulled out without anesthesia (which still pales in comparison
> to what it would take to fix our voting process, which will probably be
> akin to having an entire set of teeth pull out in the same way).   The
> reason I'm still doing it is that it's clear this RFC was flawed in its
> voting options, its substance, and the level of discussion that surrounded
> it (the last one is my opinion, the first two are facts) - and it will have
> HUGE implications on hundreds of thousands if not millions of users.  So as
> I said when I first engaged this thread - as much as I'm 'enjoying' this, I
> prefer to take the personal hit and do whatever I can to prevent our users
> from taking the hit.
>
> If we are to inflict this hit on our users - we need to have each and every
> t crossed and i dotted.
>
> Zeev

Some languages out there have an idiom for this kind of a situation:
This thread right here is making an elephant out of the fly. Meaning
something is exaggerating or make something more serious than it
actually is.

Worth noting another inconsistency here that we've missed. PHP 7.4 has
introduced many BC breaks actually already. Without this level of
problems:
- *nix build system now uses pkg-config and basically has changed so
many configure options that building this is a completely new chapter
on its own
- removed wddx
- removed interbase
- entire Backward Incompatible Changes section in the UPGRADING file:
https://github.com/php/php-src/blob/PHP-7.4/UPGRADING

The deprecation in PHP 7.4 (or even if there wouldn't be any
deprecation here at all) and removal of some short tags in PHP 8 is
the least of users problems I think.

If the next RFC on this topic would happen (in my opinion it is
pointless) it should make only something more clear. That is how to
remove them. In PHP 8.0 directly as is now the result of this RFC or
in PHP 9.0 removal and in PHP 8.0 using a compilation error. Anything
in between is a more or less a revert of the original RFC which would
then come to a question of why making these RFCs at all and why voting
even matters.

Without these kind of "hacks" PHP wouldn't even move forward anymore.
Contributing to it would be in most cases only maintenance, fixing
bugs and compatibility with platforms out there. So nothing exciting
anymore like making it more syntactically correct, more logical etc.
(these are very important changes also beside new functionality and
extensions).

-- 
Peter Kokot

--
PHP Internals - PHP Runtime Development Mailing List
To 

Re: [PHP-DEV] POC: Docker container with support for PHP and Nginx based on Debian Stretch

[Peter Cowburn]

Hi Jan,

On Tue, 30 Apr 2019 at 19:51, Jan Malaník  wrote:

> Hi,
> I'd like to introduce new variant of PHP Docker image with support for
> Nginx webserver based on Debian Stretch.
> I'm not sure if this is managed by you.


The Docker "Official image" for PHP is not maintained by the PHP Project.
>From the README file
 in their Git
repository:

This is the Git repo of the Docker "Official Image"
>  for php
>  (not to be confused with any official php
> image provided by php upstream). See the Docker Hub page
>  for the full readme on how to use this
> Docker image and for information regarding contributing and issues.
>
The full description from Docker Hub  is
> generated over in docker-library/docs
> , specifically in
> docker-library/docs/php
> .
>


> Can you please review the PR and give me comments?
> https://github.com/docker-library/php/pull/821


I'm sure the maintainers of that repository will look in on your Pull
Request soon, they are generally very responsive from my casual
observations.


>
>
> Thank you Jan
>

[PHP-DEV] POC: Docker container with support for PHP and Nginx based on Debian Stretch

[Jan Malaník]

Hi,
I'd like to introduce new variant of PHP Docker image with support for
Nginx webserver based on Debian Stretch.
I'm not sure if this is managed by you.
Can you please review the PR and give me comments?
https://github.com/docker-library/php/pull/821

Thank you Jan

Re: [PHP-DEV] [RFC] Allow throwing exceptions from __toString()

[Stanislav Malyshev]

Hi!

> Please could someone anyone who understands the implications for what
> this means for the internals of the PHP engine provide some detailed
> reasons for why this shouldn't be approved, if there are any reasons.
> 
> Otherwise voters might 'irresponsibly' vote yes, without being aware of them.

This is the tricky one because it gets into one of the corner cases of
the engine that has never worked perfectly. We have a bunch of places
where we can get some code executed in the middle of other code
executed, and it never worked particularly well. One of such places is
(un)serialization, another is error and exception handling. Generally,
running code from the guts of the engine is dangerous, because there
might be stale pointers, race conditions (not the parallel kind but the
kind "we checked it above, but below it may no longer be the case
because we run code in between"), shared mutable state, etc. and it's
nigh impossible to ensure nothing gets broken by it.

That said, the work done on the patch is super impressive. I am
reasonably sure that Nikita caught as many instances of something going
wrong when string conversion fails as humanly possible. And I agree that
banning exceptions didn't actually solve the problem anyway, because
error handlers present the same exactly issue - exceptions are just much
more prominent and immediate in their effects, but with some hostile
coding - or even some inadvertently convoluted one - you'd run into the
same issues again. Some extensions will probably have some trouble -
though with high likelyhood they already do anyway.

I think since the reason why it was banned is largely gone with this
patch it's a good step forward. There are probably still some corner
cases that would not work properly - I am especially worried about
variables left un-initialized in places where they are expected to be
initialized - like internal classes - but I think the awesome job done
on this patch is a good step forward and unless we discover some
critical issue blocking it, it makes sense to do it.

I plan to try and review the patch in my copious free time, but so far I
do not have any objections beyond "yet another place where things could
go wrong". Since that place effectively already existed, I think this
RFC is good.

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

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

[M. W. Moe]

Hello,

a bit of fuzz; no need having a dramatic posture either; php RFC system
needs to be matured; the same way
than c++ fellowship (I don't say it was without dramas over the years); in
my opinion there are two many of them
opened at the same time; some targets strictly the userspace; some language
features and finally other regards
the zend engine (absolute on purpose); maybe they should not be discussed
on the same list.

tschüss!

On Tue, Apr 30, 2019 at 11:25 AM Zeev Suraski  wrote:

> On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans  wrote:
>
> > On Mon, 29 Apr 2019, Zeev Suraski wrote:
> >
> > > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. 
> > wrote:
> > >
> > > > I think this just boils down to what is an acceptable majority, if
> > > > 2/3 is not enough then 3/4 but this is another debate altogether.
> > > >
> > >
> > > I've argued in the past that it would make sense to require a 9/10
> > majority
> > > for RFCs.  Very few RFCs that passed - only cleared a 2/3 majority.
> > > Usually (in the vast majority of cases), it either clears a nearly
> > > unanimous vote - or it doesn't even come close to 2/3.
> > >
> > > RFCs that have a high number of votes (i.e., that people feel strongly
> > > about), and barely pass the 2/3 mark - are controversial and saw
> > division.
> > > Yes, it means that out of the (almost random) group of people who are
> > > currently enabled to vote by our (flawed) voting system
> >
> > If you think it's flawed
>
>
> It's not that I think it's flawed - I know it's flawed.  It doesn't
> implement what was agreed upon when the Voting RFC was enacted.
>
>
> > , you know that the RFC process is there for
> > anybody to change it. Joe already managed twice towards what you
> > suggested in your stalled RFC:
> >
> > - https://wiki.php.net/rfc/abolish-short-votes
> > - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
> >   against this one to raise the barrier from 50%+1 to ⅔rds).
> >
>
> I'm well aware of it.  In doing that, I think we greatly complicated the
> prospects of fixing the voting eligibility - which is an infinitely hotter
> potato to handle. Both 'abolish' RFCs enjoyed popular support and had very
> little touchy subjects - unlike the topic of who gets to vote, or the
> prospect of moving to a consensus-based system.
>
> > It's absolutely fine to dislike short tags.  It's absolutely fine to
> > > believe it shouldn't have been introduced.  But the gap between that,
> > > and thinking it's fine to remove it - is very, very big.
> >
> > But the fact is that the RFC passed. And retroactively changing rules
> > because somebody don't agree with a decision is making a farce out of
> > the process.
> >
>
> I've detailed the issues with the RFC in my other reply.
>
> I'm well aware that I'm spending quite a bit of 'credit capital' by
> weighing in on this, and I'm enjoying it roughly as one would enjoy having
> their tooth pulled out without anesthesia (which still pales in comparison
> to what it would take to fix our voting process, which will probably be
> akin to having an entire set of teeth pull out in the same way).   The
> reason I'm still doing it is that it's clear this RFC was flawed in its
> voting options, its substance, and the level of discussion that surrounded
> it (the last one is my opinion, the first two are facts) - and it will have
> HUGE implications on hundreds of thousands if not millions of users.  So as
> I said when I first engaged this thread - as much as I'm 'enjoying' this, I
> prefer to take the personal hit and do whatever I can to prevent our users
> from taking the hit.
>
> If we are to inflict this hit on our users - we need to have each and every
> t crossed and i dotted.
>
> Zeev
>

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

[Zeev Suraski]

On Tue, Apr 30, 2019 at 8:14 PM Derick Rethans  wrote:

> On Mon, 29 Apr 2019, Zeev Suraski wrote:
>
> > On Sun, Apr 28, 2019 at 11:32 PM G. P. B. 
> wrote:
> >
> > > I think this just boils down to what is an acceptable majority, if
> > > 2/3 is not enough then 3/4 but this is another debate altogether.
> > >
> >
> > I've argued in the past that it would make sense to require a 9/10
> majority
> > for RFCs.  Very few RFCs that passed - only cleared a 2/3 majority.
> > Usually (in the vast majority of cases), it either clears a nearly
> > unanimous vote - or it doesn't even come close to 2/3.
> >
> > RFCs that have a high number of votes (i.e., that people feel strongly
> > about), and barely pass the 2/3 mark - are controversial and saw
> division.
> > Yes, it means that out of the (almost random) group of people who are
> > currently enabled to vote by our (flawed) voting system
>
> If you think it's flawed


It's not that I think it's flawed - I know it's flawed.  It doesn't
implement what was agreed upon when the Voting RFC was enacted.


> , you know that the RFC process is there for
> anybody to change it. Joe already managed twice towards what you
> suggested in your stalled RFC:
>
> - https://wiki.php.net/rfc/abolish-short-votes
> - https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted
>   against this one to raise the barrier from 50%+1 to ⅔rds).
>

I'm well aware of it.  In doing that, I think we greatly complicated the
prospects of fixing the voting eligibility - which is an infinitely hotter
potato to handle. Both 'abolish' RFCs enjoyed popular support and had very
little touchy subjects - unlike the topic of who gets to vote, or the
prospect of moving to a consensus-based system.

> It's absolutely fine to dislike short tags.  It's absolutely fine to
> > believe it shouldn't have been introduced.  But the gap between that,
> > and thinking it's fine to remove it - is very, very big.
>
> But the fact is that the RFC passed. And retroactively changing rules
> because somebody don't agree with a decision is making a farce out of
> the process.
>

I've detailed the issues with the RFC in my other reply.

I'm well aware that I'm spending quite a bit of 'credit capital' by
weighing in on this, and I'm enjoying it roughly as one would enjoy having
their tooth pulled out without anesthesia (which still pales in comparison
to what it would take to fix our voting process, which will probably be
akin to having an entire set of teeth pull out in the same way).   The
reason I'm still doing it is that it's clear this RFC was flawed in its
voting options, its substance, and the level of discussion that surrounded
it (the last one is my opinion, the first two are facts) - and it will have
HUGE implications on hundreds of thousands if not millions of users.  So as
I said when I first engaged this thread - as much as I'm 'enjoying' this, I
prefer to take the personal hit and do whatever I can to prevent our users
from taking the hit.

If we are to inflict this hit on our users - we need to have each and every
t crossed and i dotted.

Zeev

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

[Stanislav Malyshev]

Hi!

> Why the hell should I start compromising with someone who thinks the
> project, and by
> extensions the contributors to the project small or large, don't behave
> responsibly?!

Without getting into generalities about all contributors over all the
project lifetime, I personally think what happened with this RFC falls
short of the ideal RFC process as we'd like to see it happen in PHP. See
below on that. I don't think it's useful to assign personal blame for
anything here, but I think it may be useful to try and find the ways how
to improve.

> You say that this deprecation is an insult to our legacy users but you just
> casually
> insult (at least in my mind) the people who make this project live on.
> Or are you just remicinent of ye olden days where core devs decided willy
> nilly what
> ever they want to do with the project? Because I though the whole idea
> behind the RFC
> process is to prevent this "closed club" of core dev who can decide
> whatever they want.

There are downsides to that. For example, people voting on RFCs without
actually realizing the full extent of what they are voting for. Like
voting for a change that will start dumping people's sources to the
internet once implemented - without even realizing that would happen. I
don't know, of course, how many of the people voting yes didn't realize
that and how many did but did not care - but the following discussion
shows that this definitely wasn't properly discussed because otherwise
there wouldn't be any point in discussing it anew. And the solutions
proposed so far negate at least half of proposed benefits from the RFC.
So I am thinking - was what happened a good example of a good working
process? Do we think the situation where we're talking about changing
the approach days after the vote is how RFCs should work?

I personally think that the fact that RFC was voted in without
considering a critical BC issue and without even acknowledging it in the
RFC shows we are way too hasty to introduce breaking changes and do not
spend enough thought on evaluating their effects on existing users.

It's very easy to ask people "do you hate short tags?" and get a
resounding "yes". If you asked "do you want any old code that might use
slightly older Smarty or some other not-recently-updated dependency
suddenly spill its guts to the internet starting with 7.4?", the "yes"
might be much less enthusiastic. But that question wasn't asked. And
asking that question - the right question - is our job here. Which, in
my opinion, in this case wasn't done properly - before voting on the
RFC. Good that at least we're doing it after.

> I was willing to compromise a lot but with all the respect I have for you
> Zeev, your sheer arogance
> just made any major compromise not a thing I want to pursue anymore.

This phrasing looks suspiciously like you're basing your decisions in
the matter not on technical merits and concerns about PHP project and
its users, but on your personal grudges. I am certainly hoping this is
just because of an unartful turn of phrase and you want to rephrase that
in a way that does not give this impression.

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

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

[Zeev Suraski]

On Tue, Apr 30, 2019 at 7:03 PM Levi Morrison  wrote:

> On Tue, Apr 30, 2019 at 9:01 AM Zeev Suraski  wrote:
> >
> > On Tue, Apr 30, 2019 at 2:14 PM G. P. B. 
> wrote:
> >
> > > On Mon, 29 Apr 2019 at 16:53, Zeev Suraski  wrote:
> > >
> > >> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd 
> > >> wrote:
> > >> > Please stop doing this.
> > >>
> > >> I will gladly do so, once the project starts behaving responsibly
> again.
> > >>
> > >
> > > Honnestly, this comment right here Zeev just makes me want to not
> > > compromise at all.
> > > I think you seriously lost any hope there was that I'm going to put
> back
> > > this to a vote.
> > >
> >
> > In retrospect, I should have waited for Dan's insulting message to wear
> off
> > before replying to it.
> >
> > The fact the RFC included a confusing secondary vote, that was defined
> > against our RFC rules and may have been misunderstood by folks who voted
> > (and consequently may have resulted in different outcomes) - is
> sufficient
> > grounds to disqualify this vote and require a restarted vote on a fixed
> RFC
> > (that can include the amendments you have in mind to make the 8.0
> behavior
> > different from what the RFC proposed).
> >
> > Zeev
>
> I read our voting rules, checked with a few people, and thought about
> it for a while, and I still do not know what rule breakage you are
> referring to. How did this supposedly break our voting rules? If you
> want any support on disqualifying this RFC, you need to clearly state
> the violation.
>

The Voting RFC states:

"Additionally, an RFC may have secondary votes, which are used to *decide
implementation details*. "   (emphasis added)

The RFC in question states:
"Secondary vote: Remove PHP's short open tags in PHP 8.0."

This is not an implementation detail or even remotely one.  It's makes a
huge difference, arguably a lot bigger than the primary vote (which can be
fairly easily ignored by end users).

This is not a technicality.  I found the voting options very confusing, and
I'm sure I wasn't the only one.  In addition, I found it very weird that
many folks voted NOT to deprecate this feature in 7.4, but voted in favour
of removing it in 8.0 - which doesn't go against any of our RFCs (at least
if my memory serves me right), but does go against the way we've been
handling deprecations in the last ~15 years - you never remove a feature
without deprecating it first.  So in addition to stating a secondary vote
for something that had to be a primary vote - the 'original' primary vote
(deprecate in 7.4) is in fact an inherent requirement if the secondary vote
passes - but judging from people's votes, it's clear it wasn't properly
understood.  George has a reasonable interpretation as to what this meant -
but it's just one possible interpretation.

Ultimately, the voting decisions were flawed and against two of our rules
(one written, and one de-facto) - which means that needs to be fixed and
redone.  It's impossible to know what kind of impact laying out the voting
options properly would have had (it goes in both directions, by the way -
it may have resulted in a higher majority - or a lower one, pushing it
below the threshold).

On the substance level - I think it's clear even to the pro-deprecation
crowd that this RFC was created in haste.  There was very little discussion
over it, so little that the fact that the fact that outright removing short
tags in 8.0 (as opposed to turning them into errors) would have
catastrophic consequences wasn't even discussed.

I've heard from several folks that the right way to address this is with a
new RFC that will supercede this one.  I agree, but it should be the
authoritative RFC with the current one being annulled - given the flawed
voting options.  We need a new RFC that fixes the flaws of the current one
- both in terms of substance (8.0 behavior) and voting options.

Zeev

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

[Matteo Beccati]

Hi Björn,

On 24/04/2019 23:12, Björn Larsson wrote:
> I did a quick check on two open source libraries that I'm using,
> namely Smarty templating library and Revive ad server. A quick
> glance at hand shows that they both uses the  latest release. Smarty 3.1.33 was released 17/9 2018 and
> Revive 4.2.0 was released 23/4 2019.

I voted yes, even knowing that I'd have to do some extra OSS work.

Short open tags have been banned possibly 13 years ago in the project
coding standards, but there might still be some leftovers.

I'll make sure that will be corrected soon for Revive and its bundled
Smarty lib fork.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

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

[Derick Rethans]

On Mon, 29 Apr 2019, Zeev Suraski wrote:

> On Sun, Apr 28, 2019 at 11:32 PM G. P. B.  wrote:
> 
> > I think this just boils down to what is an acceptable majority, if 
> > 2/3 is not enough then 3/4 but this is another debate altogether.
> >
> 
> I've argued in the past that it would make sense to require a 9/10 majority
> for RFCs.  Very few RFCs that passed - only cleared a 2/3 majority.
> Usually (in the vast majority of cases), it either clears a nearly
> unanimous vote - or it doesn't even come close to 2/3.
> 
> RFCs that have a high number of votes (i.e., that people feel strongly
> about), and barely pass the 2/3 mark - are controversial and saw division.
> Yes, it means that out of the (almost random) group of people who are
> currently enabled to vote by our (flawed) voting system

If you think it's flawed, you know that the RFC process is there for 
anybody to change it. Joe already managed twice towards what you 
suggested in your stalled RFC:

- https://wiki.php.net/rfc/abolish-short-votes
- https://wiki.php.net/rfc/abolish-narrow-margins (btw, you voted 
  against this one to raise the barrier from 50%+1 to ⅔rds).

> It's absolutely fine to dislike short tags.  It's absolutely fine to 
> believe it shouldn't have been introduced.  But the gap between that, 
> and thinking it's fine to remove it - is very, very big.

But the fact is that the RFC passed. And retroactively changing rules 
because somebody don't agree with a decision is making a farce out of 
the process.

So what's next? From what I understood, Nikita and George have spoken to 
take Nikita's implementation proposals forwards. I'm pretty sure that 
this will result in another RFC on which we then can vote.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

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

[Levi Morrison]

On Tue, Apr 30, 2019 at 9:01 AM Zeev Suraski  wrote:
>
> On Tue, Apr 30, 2019 at 2:14 PM G. P. B.  wrote:
>
> > On Mon, 29 Apr 2019 at 16:53, Zeev Suraski  wrote:
> >
> >> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd 
> >> wrote:
> >> > Please stop doing this.
> >>
> >> I will gladly do so, once the project starts behaving responsibly again.
> >>
> >
> > Honnestly, this comment right here Zeev just makes me want to not
> > compromise at all.
> > I think you seriously lost any hope there was that I'm going to put back
> > this to a vote.
> >
>
> In retrospect, I should have waited for Dan's insulting message to wear off
> before replying to it.
>
> The fact the RFC included a confusing secondary vote, that was defined
> against our RFC rules and may have been misunderstood by folks who voted
> (and consequently may have resulted in different outcomes) - is sufficient
> grounds to disqualify this vote and require a restarted vote on a fixed RFC
> (that can include the amendments you have in mind to make the 8.0 behavior
> different from what the RFC proposed).
>
> Zeev

I read our voting rules, checked with a few people, and thought about
it for a while, and I still do not know what rule breakage you are
referring to. How did this supposedly break our voting rules? If you
want any support on disqualifying this RFC, you need to clearly state
the violation.

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

[Zeev Suraski]

On Tue, Apr 30, 2019 at 2:14 PM G. P. B.  wrote:

> On Mon, 29 Apr 2019 at 16:53, Zeev Suraski  wrote:
>
>> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd 
>> wrote:
>> > Please stop doing this.
>>
>> I will gladly do so, once the project starts behaving responsibly again.
>>
>
> Honnestly, this comment right here Zeev just makes me want to not
> compromise at all.
> I think you seriously lost any hope there was that I'm going to put back
> this to a vote.
>

In retrospect, I should have waited for Dan's insulting message to wear off
before replying to it.

The fact the RFC included a confusing secondary vote, that was defined
against our RFC rules and may have been misunderstood by folks who voted
(and consequently may have resulted in different outcomes) - is sufficient
grounds to disqualify this vote and require a restarted vote on a fixed RFC
(that can include the amendments you have in mind to make the 8.0 behavior
different from what the RFC proposed).

Zeev

Re: [PHP-DEV] [RFC] Allow throwing exceptions from __toString()

[Dan Ackroyd]

On Tue, 30 Apr 2019 at 14:33, Nikita Popov  wrote:
>
> Hi internals,
>
> I've already brought up this topic on list a couple of weeks ago... I've
> now updated the implementation based on feedback at the time, and turned
> this into a proper RFC:

This RFC is probably beyond the capabilities of most people to
understand the potential downsides.

Please could someone anyone who understands the implications for what
this means for the internals of the PHP engine provide some detailed
reasons for why this shouldn't be approved, if there are any reasons.

Otherwise voters might 'irresponsibly' vote yes, without being aware of them.

cheers
Dan
Ack

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

[PHP-DEV] [RFC] Allow throwing exceptions from __toString()

[Nikita Popov]

Hi internals,

I've already brought up this topic on list a couple of weeks ago... I've
now updated the implementation based on feedback at the time, and turned
this into a proper RFC:

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

Regards,
Nikita

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

[G. P. B.]

On Mon, 29 Apr 2019 at 16:53, Zeev Suraski  wrote:

> On Mon, Apr 29, 2019 at 5:19 PM Dan Ackroyd 
> wrote:
> > Please stop doing this.
>
> I will gladly do so, once the project starts behaving responsibly again.
>

Honnestly, this comment right here Zeev just makes me want to not
compromise at all.
I think you seriously lost any hope there was that I'm going to put back
this to a vote.

Why the hell should I start compromising with someone who thinks the
project, and by
extensions the contributors to the project small or large, don't behave
responsibly?!
You say that this deprecation is an insult to our legacy users but you just
casually
insult (at least in my mind) the people who make this project live on.
Or are you just remicinent of ye olden days where core devs decided willy
nilly what
ever they want to do with the project? Because I though the whole idea
behind the RFC
process is to prevent this "closed club" of core dev who can decide
whatever they want.

Also you go on about how 2/3 majority is to small when you self used even
lower margins
to get RFCs accepted. From what I know nothing prevented you to asked a 90%
acceptance
rate on all the RFCs that you proposed/co-authored if you felt that strong
about "consensus"
as the Voting process, to my understanding, only asks for minimums.

And if you think I'm being unreasonable here, well I'm not because my RFC
passed fair and
square while having a longer period then what was required at the time
(which funnily enough
you also love having small voting windows).
And do you think it would have been resonable of me to come complaining
about how my vote
failed if there would have only been 66% in favor instead of the 2/3? You
would have had no
problem then to say that it failed no more discussion needed instead of
draging this along for
about a week after the vote ended.

I was willing to compromise a lot but with all the respect I have for you
Zeev, your sheer arogance
just made any major compromise not a thing I want to pursue anymore.

I'll accept amendments to how the deprecation is handled and implemented
with any ideas that may
arise on the nikic's thread on how to handle it.
And if an RFC amendment is needed I will personaly only accept a vote on
HOW this RFC is implemented
and not a vote on IF this should be done.

And if you are not happy with this, blame yourself.


Best regards

George P. Banyard