Le 23/07/2019 à 19:13, Jan Ehrhardt a écrit :
> Derick Rethans in php.internals (Tue, 23 Jul 2019 10:00:12 +0100 (BST)):
>> DOs:
>> - Test test test test
>
> There are 2 more extensions broken in beta1 that were OK in alpha3:
> sqlsrv and pdo_sqlsrv. See
> https://github.com/microsoft/msphpsql/iss
[Had an issue with my email client, apologies if it ends up being sent
twice]
On Tue, Jul 23, 2019 at 8:55 PM G. P. B. wrote:
> Hello internals,
>
> Due to the controversy after the initial vote on the Deprecate PHP's Short
> Open Tag RFC [1] here is a new RFC to deprecate them written with the
> -Original Message-
> From: G. P. B.
> Sent: Tuesday, July 23, 2019 8:55 PM
> To: PHP internals ; Derick Rethans ;
> Peter Kokot
> Subject: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
>
> Hello internals,
>
> Due to the controversy after the initial vote on the D
That one took me a while. And then I busted out laughing. Well played
Mark.
ᐧ
On Tue, Jul 23, 2019 at 9:18 PM Mark Randall wrote:
> On 23/07/2019 10:00, Derick Rethans wrote:
> > DOs:
> > - Test test test test
> > - Tell your friends and collegues to test with their apps and projects
> > - Oh
On 23/07/2019 10:00, Derick Rethans wrote:
DOs:
- Test test test test
- Tell your friends and collegues to test with their apps and projects
- Oh yeah: test!
Derick, congratulations on your RM role, however, for your personal
well-being, I feel obliged to ask if you have recently experienced a
Hi!
> V2 remedies that by maintaining default INI behaviour, as well as
> nullifying the possibility of code / data leaks by throwing a compiler
> exception if opportunity to execute a file which contains potentially leaky code.
Oh, I thought it was already agreed upon... I thought the RFC someh
On 23/07/2019 21:58, Stanislav Malyshev wrote:
I think nicer would be to explain why we need second RFC and what it
adds to the previous one. If I didn't get some context, please explain.
The previous one, as written, carried a high probability of silently
leaking both code and data, but these
I continue to find motivations #1 and #3 utterly bizarre, especially
that "open tags not being compatible with XML" is still being used as a
justification.
That said, the depreciation and removal process looks solid, with the
exception of complete removal in PHP 8.1.
I must question if peopl
> Le 24 juil. 2019 à 00:52, Stanislav Malyshev a écrit :
>
> Hi!
>
>> My preferred solution would be to add a new built-in function that
>> re-does the mangling exactly as it used to be done. It would be no great
>> maintenance burden on us to maintain such a function for the future, but
>> it
Hi!
> My preferred solution would be to add a new built-in function that
> re-does the mangling exactly as it used to be done. It would be no great
> maintenance burden on us to maintain such a function for the future, but
> it would avoids userland having to reimplement it multiple times and
> le
Hi!
> Would you (George, Nikita) consider removing the details about the eventual
> removal of the feature from this RFC? We can run with the error for a
> bunch of releases / years, and see what happens. I don't see why we should
> necessarily decide now on something that might be 5 years or mo
On Tue, 23 Jul 2019 at 22:03, Nikita Popov wrote:
> On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins
> wrote:
>
> > On 23 July 2019 18:54:48 BST, "G. P. B."
> wrote:
> > >The only point of contention of this RFC that I potentially see is the
> > >removal in PHP 8.1 after short open tags being a Pa
On 23/07/2019 21:52, Stanislav Malyshev wrote:
This RFC does nothing to eliminate code written for short-tags - it is
impossible to eliminate with any RFC, in fact, it is impossible to
eliminate at all.
It does more to eliminate it than the previous RFC, by having at least
one version where i
Hi!
> I agree. I don't think there's a pressing need to do the "full removal" in
> PHP 8.1 in particular, so it makes more sense to this in the next major
> version (9.0), as usual.
This may be more acceptable, if we are sure there would be no short tags
code remaining anywhere by the time of 9.0
On Tue, Jul 23, 2019 at 9:10 PM Rowan Collins
wrote:
> On 23 July 2019 18:54:48 BST, "G. P. B." wrote:
> >The only point of contention of this RFC that I potentially see is the
> >removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
> >instead of it being removed in PHP 9 afte
Hi!
> I did not want to just merge the original (accepted!) implementation
> after the controversial discussion it triggered, but after reading this,
> I realize that I just wasted my time here. So much for being nice and
> giving people a fair change to reevaluate the proposal in light of the
> n
On Tue, Jul 23, 2019 at 10:22 PM Stanislav Malyshev
wrote:
> Hi!
>
> > Due to the controversy after the initial vote on the Deprecate PHP's
> Short
> > Open Tag RFC [1] here is a new RFC to deprecate them written with the
> help
> > of Nikita Popov .
>
> Could you please explain what has changed
Hi!
> That's precisely what this RFC is intended to prevent.
This RFC does nothing to eliminate code written for short-tags - it is
impossible to eliminate with any RFC, in fact, it is impossible to
eliminate at all. So the only question is what is happening when server
is encountering such code.
On 23/07/2019 21:22, Stanislav Malyshev wrote:
Worse than that, code using short open tags deployed on a server using
short_open_tag=0 will leak application code, because short open tags are
silently ignored.
That's precisely what this RFC is intended to prevent.
By deprecating *and simply re
> First, short_open_tag is an ini setting that control core language syntax.
> 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
> of the deployment environment.
While this RFC is a much
> Le 23 juil. 2019 à 19:54, G. P. B. a écrit :
>
> The only point of contention of this RFC that I potentially see is the
> removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
> instead of it being removed in PHP 9 after it having had a whole major
> version release cycle.
R
Hi!
> Due to the controversy after the initial vote on the Deprecate PHP's Short
> Open Tag RFC [1] here is a new RFC to deprecate them written with the help
> of Nikita Popov .
Could you please explain what has changed since the last time we
discussed it that makes it necessary to bring the seco
On 23 July 2019 18:54:48 BST, "G. P. B." wrote:
>The only point of contention of this RFC that I potentially see is the
>removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0
>instead of it being removed in PHP 9 after it having had a whole major
>version release cycle.
Given th
Hello internals,
Due to the controversy after the initial vote on the Deprecate PHP's Short
Open Tag RFC [1] here is a new RFC to deprecate them written with the help
of Nikita Popov .
This RFC is targeting PHP 7.4 and has an exemption to land after the
feature freeze granted by the Release Manag
Derick Rethans in php.internals (Tue, 23 Jul 2019 10:00:12 +0100 (BST)):
>DOs:
>- Test test test test
There are 2 more extensions broken in beta1 that were OK in alpha3:
sqlsrv and pdo_sqlsrv. See
https://github.com/microsoft/msphpsql/issues/999#issuecomment-514298284
--
Jan
--
PHP Internals -
Derick Rethans in php.internals (Tue, 23 Jul 2019 10:00:12 +0100 (BST)):
>DOs:
>- Test test test test
I did. Compilation of Wincache fails in 7.4-beta1:
https://github.com/php/pecl-caching-wincache/commit/def79d476ccb9ad4987d588adda2fdfbb6a80652#commitcomment-34413735
--
Jan
--
PHP Internals -
On Tue, Jul 23, 2019 at 5:00 PM Nikita Popov wrote:
> On Tue, Jun 18, 2019 at 5:10 PM Nikita Popov wrote:
>
> > Hi internals,
> >
> > In PHP 8 it will be possible to add reflectible argument and return type
> > information for internal functions (it was previously theoretically
> > possible as w
On Tue, Jun 18, 2019 at 5:10 PM Nikita Popov wrote:
> Hi internals,
>
> In PHP 8 it will be possible to add reflectible argument and return type
> information for internal functions (it was previously theoretically
> possible as well, but forbidden by policy for php-src for multiple reasons,
> wh
On Tue, 2019-07-16 at 08:00 -0700, Zeev Suraski wrote:
> > Now unanimity implies consensus however not having a unanimous vote
> does
> > not mean there is no consensus.
> > Moreover, even though "consensus" does come from the Latin
> *cōnsēnsus* (“agreement,
> > accordance, unanimity”) [3] it does
On Wed, Jul 10, 2019 at 11:38 PM Arnold Daniels <
arnold.adaniels...@gmail.com> wrote:
> Hi Nikita,
>
> Thanks for your feedback.
>
> I'll fix the textual errors you mentioned.
>
> * "To compare two numeric strings as numbers, they need to be cast to
> > floats." This may loose precision for integ
Hi all!
The PHP-7.4 branch is now in feature freeze, with the tarballs for PHP
7.4.0beta1 just having been created.
DON'Ts:
- No new features that would otherwise require an RFC
- No new features, unless they're small, self-contained, and ack-ed by
the release managers.
- No API breaks
DOs:
31 matches
Mail list logo
