Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] Deprecations for PHP 7.3

Posted by Nikita Popov 
Nikita Popov
[PHP-DEV] [RFC] Deprecations for PHP 7.3
June 24, 2018 06:50PM
Hi internals,

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

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.

Regards,
Nikita
Christoph M. Becker
[PHP-DEV] Re: [RFC] Deprecations for PHP 7.3
June 24, 2018 10:40PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 25, 2018 08:20AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 25, 2018 10:20AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 25, 2018 09:00PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 25, 2018 09:40PM
On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <[email protected]> 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.
Marco Pivetta
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 01:30PM
On Mon, Jun 25, 2018 at 9:32 PM, Sara Golemon <[email protected]> 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....
Nicolas Grekas
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 05:50PM
> 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
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 06:40PM
Hi

Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
[PHP-DEV] Re: [RFC] Deprecations for PHP 7.3
June 26, 2018 07:30PM
On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker <[email protected]>
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
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 08:20PM
On Tue, Jun 26, 2018 at 6:31 PM, Kalle Sommer Nielsen <[email protected]> wrote:

> Hi
>
> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <[email protected]
> >:
> > 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
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 09:00PM
On Mon, Jun 25, 2018 at 9:32 PM, Sara Golemon <[email protected]> wrote:

> On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <[email protected]>
> 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.
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 10:00PM
Den tir. 26. jun. 2018 kl. 20.16 skrev Nikita Popov <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 10:10PM
On Tue, Jun 26, 2018 at 9:51 PM, Kalle Sommer Nielsen <[email protected]> wrote:

> Den tir. 26. jun. 2018 kl. 20.16 skrev Nikita Popov <[email protected]
> >:
> > 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
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 10:20PM
Den tir. 26. jun. 2018 kl. 22.01 skrev Nikita Popov <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 26, 2018 10:30PM
Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph M. Becker
[PHP-DEV] Re: [RFC] Deprecations for PHP 7.3
June 26, 2018 10:50PM
On 26.06.2018 at 19:15, Nikita Popov wrote:

> On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker <[email protected]>
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 27, 2018 02:50AM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Zeev Suraski
RE: [PHP-DEV] [RFC] Deprecations for PHP 7.3
June 27, 2018 07:50AM
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


> -----Original Message-----
> From: Stanislav Malyshev [mailto:[email protected]]
> Sent: Wednesday, June 27, 2018 3:39 AM
> To: Kalle Sommer Nielsen <[email protected]>; Nikita Popov
> <[email protected]>
> Cc: Internals <[email protected]>
> Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
[PHP-DEV] Re: [RFC] Deprecations for PHP 7.3
July 04, 2018 04:10PM
On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker <[email protected]>
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 M. Becker
[PHP-DEV] Re: [RFC] Deprecations for PHP 7.3
July 04, 2018 05:30PM
On 04.07.2018 at 16:07, Nikita Popov wrote:

> On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker <[email protected]>
> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.3
July 04, 2018 07:40PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.3
July 05, 2018 12:20AM
On Wed, Jul 4, 2018 at 7:32 PM, Stanislav Malyshev <[email protected]>
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
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 05, 2018 08:20PM
On Mon, Jun 25, 2018 at 9:32 PM, Sara Golemon <[email protected]> wrote:

> On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov <[email protected]>
> 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.
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 05, 2018 10:20PM
On Tue, Jun 26, 2018 at 10:22 PM, Kalle Sommer Nielsen <[email protected]>
wrote:

> Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov <[email protected]
> >:
> > 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
Stanislav Malyshev
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 05, 2018 10:30PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 05, 2018 10:50PM
Den tor. 5. jul. 2018 kl. 22.22 skrev Stanislav Malyshev <[email protected]>:
>
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 05, 2018 10:50PM
On Thu, Jul 5, 2018 at 10:42 PM, Kalle Sommer Nielsen <[email protected]> wrote:

> Den tor. 5. jul. 2018 kl. 22.22 skrev Stanislav Malyshev <
> [email protected]>:
> >
> > 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
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 05, 2018 11:00PM
Den tor. 5. jul. 2018 kl. 22.46 skrev Nikita Popov <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Kalle Sommer Nielsen
Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3
July 06, 2018 07:00AM
Den tor. 5. jul. 2018 kl. 22.51 skrev Kalle Sommer Nielsen <[email protected]>:
>
> Den tor. 5. jul. 2018 kl. 22.46 skrev Nikita Popov <[email protected]>:
> > 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login