[RFC] Deprecations for PHP 7.3

Christoph Becker

8 years ago

On 24.06.2018 at 18:47, Nikita Popov wrote:

> This RFC collects a number of deprecations for PHP 7.3 which I consider to
> be too minor to warrant a separate proposal. However, each deprecation will
> still be voted separately.
>
> https://wiki.php.net/rfc/deprecations_php_7_3

Thanks.  FWIW, I'm +1 on all 4 proposals.

> If you have a minor deprecation in mind, but were too lazy to write an RFC
> for it, please write me a mail until tomorrow, so that it might be included
> as part of this proposal. As time is limited I don't want to include
> anything larger or controversial in this RFC though.

I've recently submitted <https://github.com/php/php-src/pull/3322> to
deprecate FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED.  I
don't think this needs an RFC, but it might be something which could be
added to this RFC?

--
Christoph M. Becker

Nikita Popov

8 years ago

On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 24.06.2018 at 18:47, Nikita Popov wrote:
>
> > This RFC collects a number of deprecations for PHP 7.3 which I consider
> to
> > be too minor to warrant a separate proposal. However, each deprecation
> will
> > still be voted separately.
> >
> > https://wiki.php.net/rfc/deprecations_php_7_3
>
> Thanks.  FWIW, I'm +1 on all 4 proposals.
>
> > If you have a minor deprecation in mind, but were too lazy to write an
> RFC
> > for it, please write me a mail until tomorrow, so that it might be
> included
> > as part of this proposal. As time is limited I don't want to include
> > anything larger or controversial in this RFC though.
>
> I've recently submitted <https://github.com/php/php-src/pull/3322> to
> deprecate FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED.  I
> don't think this needs an RFC, but it might be something which could be
> added to this RFC?
>

I've added these deprecations to the RFC. Please feel free to update the
description if you'd like to add something.

I think it would have been fine to also land these deprecations directly
(as you already wrote to internals about it in the past), but as the have
the opportunity, we might as well go through the motions.

Nikita

Christoph Becker

8 years ago

On 26.06.2018 at 19:15, Nikita Popov wrote:

> On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>
>> I've recently submitted <https://github.com/php/php-src/pull/3322> to
>> deprecate FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED.  I
>> don't think this needs an RFC, but it might be something which could be
>> added to this RFC?
>
> I've added these deprecations to the RFC. Please feel free to update the
> description if you'd like to add something.

Thanks.  It's already very well done. :)

--
Christoph M. Becker

Nikita Popov

8 years ago

On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 24.06.2018 at 18:47, Nikita Popov wrote:
>
> > This RFC collects a number of deprecations for PHP 7.3 which I consider
> to
> > be too minor to warrant a separate proposal. However, each deprecation
> will
> > still be voted separately.
> >
> > https://wiki.php.net/rfc/deprecations_php_7_3
>
> Thanks.  FWIW, I'm +1 on all 4 proposals.
>
> > If you have a minor deprecation in mind, but were too lazy to write an
> RFC
> > for it, please write me a mail until tomorrow, so that it might be
> included
> > as part of this proposal. As time is limited I don't want to include
> > anything larger or controversial in this RFC though.
>
> I've recently submitted <https://github.com/php/php-src/pull/3322> to
> deprecate FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED.  I
> don't think this needs an RFC, but it might be something which could be
> added to this RFC?
>

Procedural question: Would you prefer that the vote for this (and the other
two deprecation RFCs) is one week (the minimum voting period), or that the
vote is two weeks but the deprecations land for beta 2 rather than beta 1?

Nikita

Christoph Becker

8 years ago

On 04.07.2018 at 16:07, Nikita Popov wrote:

> On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>
>> On 24.06.2018 at 18:47, Nikita Popov wrote:
>>
>>> This RFC collects a number of deprecations for PHP 7.3 which I consider
>> to
>>> be too minor to warrant a separate proposal. However, each deprecation
>> will
>>> still be voted separately.
>>>
>>> https://wiki.php.net/rfc/deprecations_php_7_3
>>
>> Thanks.  FWIW, I'm +1 on all 4 proposals.
>>
>>> If you have a minor deprecation in mind, but were too lazy to write an
>> RFC
>>> for it, please write me a mail until tomorrow, so that it might be
>> included
>>> as part of this proposal. As time is limited I don't want to include
>>> anything larger or controversial in this RFC though.
>>
>> I've recently submitted <https://github.com/php/php-src/pull/3322> to
>> deprecate FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED.  I
>> don't think this needs an RFC, but it might be something which could be
>> added to this RFC?
>
> Procedural question: Would you prefer that the vote for this (and the other
> two deprecation RFCs) is one week (the minimum voting period), or that the
> vote is two weeks but the deprecations land for beta 2 rather than beta 1?

Hmm, it's probably best to ship the deprecations (if any) with beta1.
If the voting could be opened soon, there's still more than 1 week time.

--
Christoph M. Becker

Stas Malyshev

8 years ago

Hi!

>> Procedural question: Would you prefer that the vote for this (and the other
>> two deprecation RFCs) is one week (the minimum voting period), or that the
>> vote is two weeks but the deprecations land for beta 2 rather than beta 1?
>
> Hmm, it's probably best to ship the deprecations (if any) with beta1.
> If the voting could be opened soon, there's still more than 1 week time.

Right. That said, since deprecations are not exactly new features, I
*think* if it's impossible to do it for beta1 it'll still be ok for
beta2. But we have almost 2 weeks till beta1, so if we start vote soon,
I think beta1 may still be possible...

--
Stas Malyshev
smalyshev@gmail.com

Nikita Popov

8 years ago

On Wed, Jul 4, 2018 at 7:32 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> >> Procedural question: Would you prefer that the vote for this (and the
> other
> >> two deprecation RFCs) is one week (the minimum voting period), or that
> the
> >> vote is two weeks but the deprecations land for beta 2 rather than beta
> 1?
> >
> > Hmm, it's probably best to ship the deprecations (if any) with beta1.
> > If the voting could be opened soon, there's still more than 1 week time.
>
> Right. That said, since deprecations are not exactly new features, I
> *think* if it's impossible to do it for beta1 it'll still be ok for
> beta2. But we have almost 2 weeks till beta1, so if we start vote soon,
> I think beta1 may still be possible...
>

I'd be fine with opening voting tomorrow. I was mainly concerned about the
two week minimum discussion period here, but as the active discussion seems
to have died down, I agree that it may be better to have a longer vote
rather than a longer discussion window.

Nikita

Stas Malyshev

8 years ago

Hi!

> This RFC collects a number of deprecations for PHP 7.3 which I consider to
> be too minor to warrant a separate proposal. However, each deprecation will
> still be voted separately.
>
> https://wiki.php.net/rfc/deprecations_php_7_3

> Undocumented mbstring function aliases

Not sure what this would give us. Yes, they are undocumented, but do
they hurt anything?

> String search functions with integer needle

That is definitely weird. However, I am not sure what should happen in
non-integer cases - i.e. what happens if I pass a double? Or a boolean?

> fgetss() function and string.strip_tags filter

I think I disagree with "strip_tags() itself, due to its limitations and
known bugs, already has very few legitimate applications" and certainly
the manual does not have any notice to that effect. I am not sure what
is the reason to remove this functionality, would like to hear more
about it - and it doesn't seem so minor as to be 1/4 of the RFC. If I
had to vote today, I'd probably vote no just on this point.
It may be true that strip_tags() alone without streaming part could be
implemented easier. However, that is not a reason to drop functionality
by itself, unless it's already completely broken. If it is, I'd like to
hear more about it.

> Defining a free-standing assert() function

Sounds good.

--
Stas Malyshev
smalyshev@gmail.com

Christoph Becker

8 years ago

On 25.06.2018 at 08:12, Stanislav Malyshev wrote:

>> fgetss() function and string.strip_tags filter
>
> I think I disagree with "strip_tags() itself, due to its limitations and
> known bugs, already has very few legitimate applications" and certainly
> the manual does not have any notice to that effect. I am not sure what
> is the reason to remove this functionality, would like to hear more
> about it - and it doesn't seem so minor as to be 1/4 of the RFC. If I
> had to vote today, I'd probably vote no just on this point.
> It may be true that strip_tags() alone without streaming part could be
> implemented easier. However, that is not a reason to drop functionality
> by itself, unless it's already completely broken. If it is, I'd like to
> hear more about it.

There are multiple bug reports regarding strip_tags()'s broken behavior
on (slightly) malformed HTML, e.g. <https://bugs.php.net/63212>,
<https://bugs.php.net/64430> and <https://bugs.php.net/74371>, which
renders the function unusable on arbitrary user supplied input.

--
Christoph M. Becker

Stas Malyshev

8 years ago

Hi!

> There are multiple bug reports regarding strip_tags()'s broken behavior
> on (slightly) malformed HTML, e.g. <https://bugs.php.net/63212>,
> <https://bugs.php.net/64430> and <https://bugs.php.net/74371>, which
> renders the function unusable on arbitrary user supplied input.

I see a very corner-case issues that don't really make it "unusable" -
in fact, in these examples it looks like it chooses the most safe
approach. Which means it can't be used to fix broken HTML or parse
Javascript scripts, but that's not the point of this function anyway.

--
Stas Malyshev
smalyshev@gmail.com

Sara Golemon

8 years ago

On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> https://wiki.php.net/rfc/deprecations_php_7_3
>
> Undocumented mbstring function aliases
>

Yeah, if they're just dumb aliases, then it's a slight gain to narrow
the symbol table by removing duplicates.  A modest composer package
(nay, include file) would be sufficient to provide a bridge for
existing projects which use the removed aliases once they're gone.
This deprecation isn't *needed*, but it's also fairly low impact. 🤷

> String search functions with integer needle
>

Agree with stas, the wtf quotient on this one is high.  Mitigating
this is the availability of strict types, but even still I think
deprecating the behavior altogether is a wise move.  Callers can
easily insert a call to chr() (or IntlChar::chr() ) to maintain the
old behavior in a version agnostic way. 😕

> fgetss() function and string.strip_tags filter
>

"...these functions seem to be of very little utility..." [citation needed]
Anecdotally I struggle to imagine the use-case, but my imagination
isn't what it once was.  There's not a trivial workaround for someone
who's dealing with a large/streaming data source from which they want
to strip tags.  Deprecating this should come at a higher standard of:
proving that it is used, providing a userspace replacement, or both.
😤

> Defining a free-standing assert() function
>

Eww, yeah. I can see that problem.  I'm not a huge fan of banning all
namespaced assert() function declarations, but it's certainly the most
direct "solution" to the problem.  A very quick scan of github only
shows one effected usage in a repo with no followers/stars apart from
the owner.  Given the lack of whole-program analysis, it's either ban
the declarations, or abandon elision.  Frankly, the number of people
taking advantage of the free dev-only check is probably way higher
than the number trying to define a function called 'assert' so.... 😬

-Sara

Marco Pivetta

8 years ago

On Mon, Jun 25, 2018 at 9:32 PM, Sara Golemon <pollita@php.net> wrote:

> > Defining a free-standing assert() function
> >
> Eww, yeah. I can see that problem.  I'm not a huge fan of banning all
> namespaced assert() function declarations, but it's certainly the most
> direct "solution" to the problem.  A very quick scan of github only
> shows one effected usage in a repo with no followers/stars apart from
> the owner.  Given the lack of whole-program analysis, it's either ban
> the declarations, or abandon elision.  Frankly, the number of people
> taking advantage of the free dev-only check is probably way higher
> than the number trying to define a function called 'assert' so.... 😬

Or require a FQN for an imported `assert()`? Importing functions is getting
traction.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Nikita Popov

8 years ago

On Mon, Jun 25, 2018 at 9:32 PM, Sara Golemon <pollita@php.net> wrote:

> On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > https://wiki.php.net/rfc/deprecations_php_7_3
> >
> > Undocumented mbstring function aliases
> >
> Yeah, if they're just dumb aliases, then it's a slight gain to narrow
> the symbol table by removing duplicates.  A modest composer package
> (nay, include file) would be sufficient to provide a bridge for
> existing projects which use the removed aliases once they're gone.
> This deprecation isn't *needed*, but it's also fairly low impact. 🤷
>
> > String search functions with integer needle
> >
> Agree with stas, the wtf quotient on this one is high.  Mitigating
> this is the availability of strict types, but even still I think
> deprecating the behavior altogether is a wise move.  Callers can
> easily insert a call to chr() (or IntlChar::chr() ) to maintain the
> old behavior in a version agnostic way. 😕
>
> > fgetss() function and string.strip_tags filter
> >
> "...these functions seem to be of very little utility..." [citation needed]
> Anecdotally I struggle to imagine the use-case, but my imagination
> isn't what it once was.  There's not a trivial workaround for someone
> who's dealing with a large/streaming data source from which they want
> to strip tags.  Deprecating this should come at a higher standard of:
> proving that it is used, providing a userspace replacement, or both.
> 😤
>

Some background here. Originally this RFC suggested to deprecate
strip_tags() entirely, but based on early feedback I decided not to.

The original motivation for strip_tags() was basically that the function
has few legitimate applications, but is easy to use in the wrong way. The
two misuses I have seen often enough to motivate a deprecation are:

a) Without allowed_tags: People using strip_tags() where they really just
want htmlspecialchars(). It's obvious to you and I that this is a bad idea,
but there are really people out there who do this. I've actually had
discussions on StackOverflow with people who did not want to believe that,
yes, using htmlspecialchars() is safe and they do not need to use
strip_tags() to eliminate XSS threats. Using strip_tags() for this purpose
is made worse by the fact that it cuts off all text after a standalone <.

b) With allowed_tags: People thinking that using this is safe. Because
attributes on allowed tags are preserved, strip_tags() in this mode
provides zero safety guarantees. The correct alternative is to use
something like HtmlPurifier.

However, there are also not entirely illegitimate applications:

a) Without allowed_tags: Convert HTML to plain-text for use in emails. This
is not a good solution, but it's a quick&dirty way to make things work.

b) With allowed_tags: In combination with WYSIWYG editors that generate
certain HTML tags and under the assumption that the input is completely
trusted. The use of strip_tags() here is more about preventing the users
from shooting themselves in the foot than about security.

Of course, there are also the implementation issues with strip_tags. I
already mentioned that one problem is that all text after < is cut off and
cmb pointed to some more bugs. This makes strip_tags() over-aggressive in
the cases where it's use might generally be legitimate.

This RFC goes the conservative route of only deprecating the streaming
functionality, which is the main source of complexity in the
implementation, while also being the least useful aspect of it.

> > Defining a free-standing assert() function
> >
> Eww, yeah. I can see that problem.  I'm not a huge fan of banning all
> namespaced assert() function declarations, but it's certainly the most
> direct "solution" to the problem.  A very quick scan of github only
> shows one effected usage in a repo with no followers/stars apart from
> the owner.  Given the lack of whole-program analysis, it's either ban
> the declarations, or abandon elision.  Frankly, the number of people
> taking advantage of the free dev-only check is probably way higher
> than the number trying to define a function called 'assert' so.... 😬
>

TBH I'd be fine with just ignoring this issue. I only included this because
I got some loud complaints from some users who tried to do something like
this and ran into the issue.

Nikita

Nikita Popov

8 years ago

On Mon, Jun 25, 2018 at 9:32 PM, Sara Golemon <pollita@php.net> wrote:

> On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > https://wiki.php.net/rfc/deprecations_php_7_3
> >
> > Undocumented mbstring function aliases
> >
> Yeah, if they're just dumb aliases, then it's a slight gain to narrow
> the symbol table by removing duplicates.  A modest composer package
> (nay, include file) would be sufficient to provide a bridge for
> existing projects which use the removed aliases once they're gone.
> This deprecation isn't *needed*, but it's also fairly low impact. 🤷
>
> > String search functions with integer needle
> >
> Agree with stas, the wtf quotient on this one is high.  Mitigating
> this is the availability of strict types, but even still I think
> deprecating the behavior altogether is a wise move.  Callers can
> easily insert a call to chr() (or IntlChar::chr() ) to maintain the
> old behavior in a version agnostic way. 😕
>
> > fgetss() function and string.strip_tags filter
> >
> "...these functions seem to be of very little utility..." [citation needed]
> Anecdotally I struggle to imagine the use-case, but my imagination
> isn't what it once was.  There's not a trivial workaround for someone
> who's dealing with a large/streaming data source from which they want
> to strip tags.  Deprecating this should come at a higher standard of:
> proving that it is used, providing a userspace replacement, or both.
> 😤
>

As an insight into how much this functionality is used from a somewhat
unexpected direction: While implementing the deprecation, I found out that
the string.strip_tags filter does not have a single test and has been
segfaulting on construction since PHP 7.0 if no allowed tags are specified
(and performed OOB reads if they were specified). These issues have been
fixed in
https://github.com/php/php-src/commit/791f07e4f06a943bd7892bdc539a7313fb3d6d1e
.

Nikita

Nicolas Grekas

8 years ago

> https://wiki.php.net/rfc/deprecations_php_7_3
>

Do you think we could ass Serializable to the list?
See your own arguments in https://externals.io/message/98834 :)

Nicolas

Kalle Sommer Nielsen

8 years ago

Hi

Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <nikita.ppv@gmail.com>:

> If you have a minor deprecation in mind, but were too lazy to write an RFC
> for it, please write me a mail until tomorrow, so that it might be included
> as part of this proposal. As time is limited I don't want to include
> anything larger or controversial in this RFC though.

As suggested in the past, I would like to add the following to this
list (if its not too late):

- The (real) type-cast and its function, is_real(). There doesn't
seem to be any support for reals in settype() anyway (side note: in
the implementation of settype() it claims "double" is deprecated)
- Function variants that already exists as constants, php_sapi_name()

> PHP_SAPI, pi() > M_PI, phpversion() > PHP_VERSION etc

- enable_dl ini directive, as dl() is only operational for CLI and Embed anyway
- pdo_odbc.db2_instance_name ini directive, its been marked as
deprecated and mentioned in the manual since PHP 5.1.11 that it will
*certainly* be removed in the future
- The 'b' constant string prefix, its not used and was meant as to
make code ready for PHP6, should the time come where we want to add a
feature that uses this, we can always re-add it

Other things thats been suggested by others in the past:

- Second parameter of spl_autoload() and its associated function
spl_autoload_extensions()
- hebrevc() -- same as hebrev() + nl2br(), perhaps even deprecate
hebrev() too (see next one)
- convert_cyr_string() -- Point to mb_convert_encoding() / iconv
- Remove get_magic_quotes_gpc(), not been working for what, 5+ years now?
- allow_url_include ini option, this can lead to all kinds of
security complications anyway
- The alternative string interpolation syntaxes (${varName},
${varName['offset']}, ${expr}) and make them more consistent
({$varName}, {$varName['offset']}, {${expr}})
- The historial parameter handling that works both ways for
implode(), should be unified to match that of explode()

I could probably think of more, but thats all I got for now. I can and
will of course help produce the relevant patches should it be needed
for most of these things.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Nikita Popov

8 years ago

On Tue, Jun 26, 2018 at 6:31 PM, Kalle Sommer Nielsen <kalle@php.net> wrote:

> Hi
>
> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <nikita.ppv@gmail.com
> >:
> > If you have a minor deprecation in mind, but were too lazy to write an
> RFC
> > for it, please write me a mail until tomorrow, so that it might be
> included
> > as part of this proposal. As time is limited I don't want to include
> > anything larger or controversial in this RFC though.
>
> As suggested in the past, I would like to add the following to this
> list (if its not too late):
>
>  - The (real) type-cast and its function, is_real(). There doesn't
> seem to be any support for reals in settype() anyway (side note: in
> the implementation of settype() it claims "double" is deprecated)
>  - Function variants that already exists as constants, php_sapi_name()
> > PHP_SAPI, pi() > M_PI, phpversion() > PHP_VERSION etc
>  - enable_dl ini directive, as dl() is only operational for CLI and Embed
> anyway
>  - pdo_odbc.db2_instance_name ini directive, its been marked as
> deprecated and mentioned in the manual since PHP 5.1.11 that it will
> *certainly* be removed in the future
>

Feel free to add this one to the RFC, if you know what the background for
the deprecation is. Given that the manual already marks it as deprecated
for so long, this seems like a mere technicality.

>  - The 'b' constant string prefix, its not used and was meant as to
> make code ready for PHP6, should the time come where we want to add a
> feature that uses this, we can always re-add it
>
> Other things thats been suggested by others in the past:
>
>  - Second parameter of spl_autoload() and its associated function
> spl_autoload_extensions()
>  - hebrevc() -- same as hebrev() + nl2br(), perhaps even deprecate
> hebrev() too (see next one)
>  - convert_cyr_string() -- Point to mb_convert_encoding() / iconv
>  - Remove get_magic_quotes_gpc(), not been working for what, 5+ years now?
>  - allow_url_include ini option, this can lead to all kinds of
> security complications anyway
>  - The alternative string interpolation syntaxes (${varName},
> ${varName['offset']}, ${expr}) and make them more consistent
> ({$varName}, {$varName['offset']}, {${expr}})
>  - The historial parameter handling that works both ways for
> implode(), should be unified to match that of explode()
>
> I could probably think of more, but thats all I got for now. I can and
> will of course help produce the relevant patches should it be needed
> for most of these things.
>

Given the recent discussions about having a PHP 7.4 release for additional
deprecations, I'm going to punt on the rest. While they may be no-brainers
to you and I, a lot of those are actually quite controversial (e.g. there
was an RFC to deprecate b' in 7.2 and it was declined -- go figure!)

I'd suggest that you already open up the next deprecation RFC, to make sure
these are not forgotten. Some of them should probably get separate
proposals altogether (especially the var interpolation syntax).

Nikita

Kalle Sommer Nielsen

8 years ago

Den tir. 26. jun. 2018 kl. 20.16 skrev Nikita Popov <nikita.ppv@gmail.com>:

> Feel free to add this one to the RFC, if you know what the background for the deprecation is. Given that the manual already marks it as deprecated for so long, this seems like a mere technicality.

I added the pdo_odbc.db2_instance_name to the RFC including 2 options
which is up to you to decide for with the relevant patches included.

> Given the recent discussions about having a PHP 7.4 release for additional deprecations, I'm going to punt on the rest. While they may be no-brainers to you and I, a lot of those are actually quite controversial (e.g. there was an RFC to deprecate b' in 7.2 and it was declined -- go figure!)
>
> I'd suggest that you already open up the next deprecation RFC, to make sure these are not forgotten. Some of them should probably get separate proposals altogether (especially the var interpolation syntax).
>
> Nikita

I agree that a lot of them are controversial, and perhaps its a good
idea to start flesh them out for our users and fellow contributors
already now. I began a draft based on your 7.3 RFC for 7.4[1]. Ps I
took the liberty of adding your name as the RFC author.

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

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Nikita Popov

8 years ago

On Tue, Jun 26, 2018 at 9:51 PM, Kalle Sommer Nielsen <kalle@php.net> wrote:

> Den tir. 26. jun. 2018 kl. 20.16 skrev Nikita Popov <nikita.ppv@gmail.com
> >:
> > Feel free to add this one to the RFC, if you know what the background
> for the deprecation is. Given that the manual already marks it as
> deprecated for so long, this seems like a mere technicality.
>
> I added the pdo_odbc.db2_instance_name to the RFC including 2 options
> which is up to you to decide for with the relevant patches included.
>

Thanks for adding it. Unless there is a particular reason to rush here, I'd
suggest to follow the usual process and formally deprecate the option prior
to removal.

As a clarification, what is the alternative to using this ini setting? I
guess you can just explicit set the DB2INSTANCE env var, but that probably
has the same issues. Is there a "correct" way to do this? (Sorry if it's
obvious, I'm not familiar with ODBC.)

> > Given the recent discussions about having a PHP 7.4 release for
> additional deprecations, I'm going to punt on the rest. While they may be
> no-brainers to you and I, a lot of those are actually quite controversial
> (e.g. there was an RFC to deprecate b' in 7.2 and it was declined -- go
> figure!)
> >
> > I'd suggest that you already open up the next deprecation RFC, to make
> sure these are not forgotten. Some of them should probably get separate
> proposals altogether (especially the var interpolation syntax).
> >
> > Nikita
>
> I agree that a lot of them are controversial, and perhaps its a good
> idea to start flesh them out for our users and fellow contributors
> already now. I began a draft based on your 7.3 RFC for 7.4[1]. Ps I
> took the liberty of adding your name as the RFC author.
>
> [1] https://wiki.php.net/rfc/deprecations_php_7_4
>

Thanks!

Nikita

Kalle Sommer Nielsen

8 years ago

Den tir. 26. jun. 2018 kl. 22.01 skrev Nikita Popov <nikita.ppv@gmail.com>:

> Thanks for adding it. Unless there is a particular reason to rush here, I'd suggest to follow the usual process and formally deprecate the option prior to removal.

I don't think theres a need for a rush here, tho I wasn't sure how you
prefered we handled the ini directive deprecation, I thought adding it
to main.c would be too "noisy".

> As a clarification, what is the alternative to using this ini setting? I guess you can just explicit set the DB2INSTANCE env var, but that probably has the same issues. Is there a "correct" way to do this? (Sorry if it's obvious, I'm not familiar with ODBC.)

I'm not too familiar with it either, I just remember it from way back
then when I began the crusade to kill old functionality in the 5.3
development days. I don't think there is any other alternative than
setting it manually, which still creates the same issues as what it
already does not but forces our users to be explicit about it. I
personally don't like such magic behind the scenes.

As for any correct way, I don't think there is any other, given how
the ibm_db2 pecl package mimics the same behavior as pdo_odbc does,
but then again the IBM folks have not been the fastest to update their
extensions, so maybe there there is a new way to do it now but I doubt
it. I don't really have the interest to dig too much into it either.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Stas Malyshev

8 years ago

Hi!

>  - The (real) type-cast and its function, is_real(). There doesn't
> seem to be any support for reals in settype() anyway (side note: in
> the implementation of settype() it claims "double" is deprecated)
>  - Function variants that already exists as constants, php_sapi_name()
>> PHP_SAPI, pi() > M_PI, phpversion() > PHP_VERSION etc

Weighting bc preak potential vs. improvement benefit, I am not sure it's
worth it for both. Maybe for "real" it's ok as I haven't really seen
anybody using it in ages, looks like most Fortran programmers either
retired or aren't using PHP :)

>  - enable_dl ini directive, as dl() is only operational for CLI and Embed anyway

Makes sense.

>  - The 'b' constant string prefix, its not used and was meant as to
> make code ready for PHP6, should the time come where we want to add a
> feature that uses this, we can always re-add it

Yeah this one we probably just have to remove, it doesn't do anything now.

> Other things thats been suggested by others in the past:
>
>  - Second parameter of spl_autoload() and its associated function
> spl_autoload_extensions()

Why?

>  - hebrevc() -- same as hebrev() + nl2br(), perhaps even deprecate
> hebrev() too (see next one)

Probably less useful now that browsers finally can render bidi texts
properly, but may be still useable for workloads where bidi rendering is
not available. And I see no problem with function doing something that
is achievable by other functions.

>  - convert_cyr_string() -- Point to mb_convert_encoding() / iconv

Maybe just make it a pseudo-alias for iconv?

>  - The alternative string interpolation syntaxes (${varName},
> ${varName['offset']}, ${expr}) and make them more consistent
> ({$varName}, {$varName['offset']}, {${expr}})

I'm not sure how one is "more consistent" than the other.

>  - The historial parameter handling that works both ways for
> implode(), should be unified to match that of explode()

I'd advise against messing with such widely used function as implode()...

--
Stas Malyshev
smalyshev@gmail.com

Zeev Suraski

8 years ago

Sorry for top posting, but should we be discussing these at this point?  If these are targeting 7.4, I think we probably want to focus on the ones slated to 7.3 at this point.

Perhaps we can add some further blurb (maybe in a box) that despite the RFC acronym, at this point this is just a list of items to discuss at a future time..?

Zeev

David Zuelke

8 years ago

On Tue, Jun 26, 2018 at 6:32 PM Kalle Sommer Nielsen <kalle@php.net> wrote:

>
> Hi
>
> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <nikita.ppv@gmail.com>:
> > If you have a minor deprecation in mind, but were too lazy to write an RFC
> > for it, please write me a mail until tomorrow, so that it might be included
> > as part of this proposal. As time is limited I don't want to include
> > anything larger or controversial in this RFC though.
>
> As suggested in the past, I would like to add the following to this
> list (if its not too late):
>
>  - The (real) type-cast and its function, is_real(). There doesn't
> seem to be any support for reals in settype() anyway (side note: in
> the implementation of settype() it claims "double" is deprecated)
>  - Function variants that already exists as constants, php_sapi_name()
> > PHP_SAPI, pi() > M_PI, phpversion() > PHP_VERSION etc

Keep in mind you can do phpversion("extensionname"), so that function
at least can't be removed, as the constant doesn't provide the same
functionality.

David

Kalle Sommer Nielsen

8 years ago

Den man. 9. jul. 2018 kl. 21.22 skrev David Zuelke <dzuelke@salesforce.com>:

> Keep in mind you can do phpversion("extensionname"), so that function
> at least can't be removed, as the constant doesn't provide the same
> functionality.

Sure, but almost all of the core extensions return PHP_VERSION anyway
(thanks to Peter K.) and the information is still available with echo
(new ReflectionExtension('extensionname'))->getVersion(); and I doubt
there is a massive usage so the impact is very minimal and therefore I
believe its a fair compromise.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Kalle Sommer Nielsen

8 years ago

Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <nikita.ppv@gmail.com>:

> If you have a minor deprecation in mind, but were too lazy to write an RFC
> for it, please write me a mail until tomorrow, so that it might be included
> as part of this proposal. As time is limited I don't want to include
> anything larger or controversial in this RFC though.

I took the liberty and added the FILTER_SANITIZE_MAGIC_QUOTES to the
RFC so we may once and for all get rid of magic_quotes.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Nikita Popov

8 years ago

On Tue, Jun 26, 2018 at 10:22 PM, Kalle Sommer Nielsen <kalle@php.net>
wrote:

> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <nikita.ppv@gmail.com
> >:
> > If you have a minor deprecation in mind, but were too lazy to write an
> RFC
> > for it, please write me a mail until tomorrow, so that it might be
> included
> > as part of this proposal. As time is limited I don't want to include
> > anything larger or controversial in this RFC though.
>
> I took the liberty and added the FILTER_SANITIZE_MAGIC_QUOTES to the
> RFC so we may once and for all get rid of magic_quotes.
>

After looking into this, I think that FILTER_SANITIZE_MAGIC_QUOTES may be a
legitimate filter, which just has a bad name. Next to other filters that
perform htmlspecialchars and urlencode, it makes sense that there is also a
filter that performs addslashes. Maybe we should just rename this filter to
something which is not tainted by the "magic quotes" terminology?

Nikita

Stas Malyshev

8 years ago

Hi!

> After looking into this, I think that FILTER_SANITIZE_MAGIC_QUOTES may be a
> legitimate filter, which just has a bad name. Next to other filters that
> perform htmlspecialchars and urlencode, it makes sense that there is also a
> filter that performs addslashes. Maybe we should just rename this filter to
> something which is not tainted by the "magic quotes" terminology?

Makes sense. There's nothing specially evil in addslashes if used in
appropriate context. Also, for those that are newer to PHP, "magic
quotes" means very little. So it's a bad name from various perspectives.
Having something like FILTER_SANITIZE_ADD_SLASHES would be fine.

--
Stas Malyshev
smalyshev@gmail.com

Kalle Sommer Nielsen

8 years ago

Den tor. 5. jul. 2018 kl. 22.22 skrev Stanislav Malyshev <smalyshev@gmail.com>:

>
> Hi!
>
> > After looking into this, I think that FILTER_SANITIZE_MAGIC_QUOTES may be a
> > legitimate filter, which just has a bad name. Next to other filters that
> > perform htmlspecialchars and urlencode, it makes sense that there is also a
> > filter that performs addslashes. Maybe we should just rename this filter to
> > something which is not tainted by the "magic quotes" terminology?
>
> Makes sense. There's nothing specially evil in addslashes if used in
> appropriate context. Also, for those that are newer to PHP, "magic
> quotes" means very little. So it's a bad name from various perspectives.
> Having something like FILTER_SANITIZE_ADD_SLASHES would be fine.

Thinking some more about it, I kinda agree with the sentiment and I
think a rename is much better as it doesn't really hurt. We could add
an alias constant instead and provoke an E_DEPRECATED if the old one
is used (given we don't give the filter the same numeric value).

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Nikita Popov

8 years ago

On Thu, Jul 5, 2018 at 10:42 PM, Kalle Sommer Nielsen <kalle@php.net> wrote:

> Den tor. 5. jul. 2018 kl. 22.22 skrev Stanislav Malyshev <
> smalyshev@gmail.com>:
> >
> > Hi!
> >
> > > After looking into this, I think that FILTER_SANITIZE_MAGIC_QUOTES may
> be a
> > > legitimate filter, which just has a bad name. Next to other filters
> that
> > > perform htmlspecialchars and urlencode, it makes sense that there is
> also a
> > > filter that performs addslashes. Maybe we should just rename this
> filter to
> > > something which is not tainted by the "magic quotes" terminology?
> >
> > Makes sense. There's nothing specially evil in addslashes if used in
> > appropriate context. Also, for those that are newer to PHP, "magic
> > quotes" means very little. So it's a bad name from various perspectives.
> > Having something like FILTER_SANITIZE_ADD_SLASHES would be fine.
>
> Thinking some more about it, I kinda agree with the sentiment and I
> think a rename is much better as it doesn't really hurt. We could add
> an alias constant instead and provoke an E_DEPRECATED if the old one
> is used (given we don't give the filter the same numeric value).
>

Sounds reasonable to me. My only question would be when we would start
emitting the deprecation notice. I'm not a fan of deprecating things in the
same release as the alternative is introduced, so I would suggest to add
the new alias in PHP 7.3 and perform the deprecation in PHP 7.4.

Nikita

Kalle Sommer Nielsen

8 years ago

Den tor. 5. jul. 2018 kl. 22.46 skrev Nikita Popov <nikita.ppv@gmail.com>:

> Sounds reasonable to me. My only question would be when we would start emitting the deprecation notice. I'm not a fan of deprecating things in the same release as the alternative is introduced, so I would suggest to add the new alias in PHP 7.3 and perform the deprecation in PHP 7.4.

I agree here, I don't think a simple constant would hurt too much to
add outside the scope of this RFC so I will go ahead and do soonish
that if no one else objects. Then we can move the section to the 7.4
Deprecation WIP RFC.

All in all I think its a much cleaner migration path

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Kalle Sommer Nielsen

8 years ago

Den tor. 5. jul. 2018 kl. 22.51 skrev Kalle Sommer Nielsen <kalle@php.net>:

>
> Den tor. 5. jul. 2018 kl. 22.46 skrev Nikita Popov <nikita.ppv@gmail.com>:
> > Sounds reasonable to me. My only question would be when we would start emitting the deprecation notice. I'm not a fan of deprecating things in the same release as the alternative is introduced, so I would suggest to add the new alias in PHP 7.3 and perform the deprecation in PHP 7.4.
>
> I agree here, I don't think a simple constant would hurt too much to
> add outside the scope of this RFC so I will go ahead and do soonish
> that if no one else objects. Then we can move the section to the 7.4
> Deprecation WIP RFC.

I wrote a quick patch[1] for this (look away from the deprecation
warning), which basically adds a new alias 'add_slashes', this seemed
like the easiest way to go about it. While looking into ext/filter it
seems there are no implementations for INPUT_SESSION and
INPUT_REQUEST. I doubt there is any intention to implement these so
they could be potentials for adding a deprecation for (or simply
removal as they just yield an E_WARNING when used anyway)[2].


[1] https://gist.github.com/KalleZ/cce52f230d599501373b15729ec85bfc
[2] https://git.php.net/?p=php-src.git;a=blob;f=ext/filter/filter.c;h=56c93199f0bf4f713eeb81c0dfddb910b02b9618;hb=HEAD#l547

--
regards,

Kalle Sommer Nielsen
kalle@php.net

Nikita Popov

8 years ago

On Fri, Jul 6, 2018 at 6:50 AM, Kalle Sommer Nielsen <kalle@php.net> wrote:

> Den tor. 5. jul. 2018 kl. 22.51 skrev Kalle Sommer Nielsen <kalle@php.net
> >:
> >
> > Den tor. 5. jul. 2018 kl. 22.46 skrev Nikita Popov <nikita.ppv@gmail.com
> >:
> > > Sounds reasonable to me. My only question would be when we would start
> emitting the deprecation notice. I'm not a fan of deprecating things in the
> same release as the alternative is introduced, so I would suggest to add
> the new alias in PHP 7.3 and perform the deprecation in PHP 7.4.
> >
> > I agree here, I don't think a simple constant would hurt too much to
> > add outside the scope of this RFC so I will go ahead and do soonish
> > that if no one else objects. Then we can move the section to the 7.4
> > Deprecation WIP RFC.
>
> I wrote a quick patch[1] for this (look away from the deprecation
> warning), which basically adds a new alias 'add_slashes', this seemed
> like the easiest way to go about it. While looking into ext/filter it
> seems there are no implementations for INPUT_SESSION and
> INPUT_REQUEST. I doubt there is any intention to implement these so
> they could be potentials for adding a deprecation for (or simply
> removal as they just yield an E_WARNING when used anyway)[2].
>
>
> [1] https://gist.github.com/KalleZ/cce52f230d599501373b15729ec85bfc
> [2] https://git.php.net/?p=php-src.git;a=blob;f=ext/filter/filter.c;h=
> 56c93199f0bf4f713eeb81c0dfddb910b02b9618;hb=HEAD#l547
>

I assume that we're going forward with the addition of the alias, so I
moved the FILTER_SANITIZE_MAGIC_QUOTES deprecation from the PHP 7.3 to the
PHP 7.4 deprecations RFC.

I'll start the vote on this RFC (and the case-insensitive constants RFC)
tomorrow, with a duration of one week. I was holding off on these votes
because earlier comments in the typed references RFC thread made it appear
like a change to the release schedule was imminent, but as the RMs haven't
made a final decision yet and I can't hold off these votes further, I'll
have to keep them within the current schedule

Nikita

Christoph Becker

8 years ago

On 08.07.2018 at 23:18, Nikita Popov wrote:

> I'll start the vote on this RFC (and the case-insensitive constants RFC)
> tomorrow, with a duration of one week. I was holding off on these votes
> because earlier comments in the typed references RFC thread made it appear
> like a change to the release schedule was imminent, but as the RMs haven't
> made a final decision yet and I can't hold off these votes further, I'll
> have to keep them within the current schedule

Sorry, that there has not been any decision yet.  However, Sara
suggested that this decision is not solely up to the RMs[1], and I
wouldn't know how to decide it then[2], since there has been at least
one objection[3].

[1] <https://externals.io/message/102333#102613>
[2] <https://externals.io/message/102333#102648>
[3] <https://externals.io/message/102333#102640>

--
Christoph M. Becker

Kalle Sommer Nielsen

8 years ago

Den søn. 8. jul. 2018 kl. 23.18 skrev Nikita Popov <nikita.ppv@gmail.com>:

> I assume that we're going forward with the addition of the alias, so I moved the FILTER_SANITIZE_MAGIC_QUOTES deprecation from the PHP 7.3 to the PHP 7.4 deprecations RFC.

I implemented the 'add_slashes' filter to master so we should all be
good at that department. I will take care of updating the portion of
the 7.4 RFC to mention this new addition.

--
regards,

Kalle Sommer Nielsen
kalle@php.net