Hi all,
I would like to propose INI set/get function deprecation, raise
E_DEPRECATED,
and make PHP_INI_MH() use the CODING_STANDARDS.
For example, session module has following INI set/get functions
- http://php.net/manual/en/function.session-save-path.php
- http://php.net/manual/en/function.session-module-name.php
- http://php.net/manual/en/function.session-cache-expire.php
- http://php.net/manual/en/function.session-cache-limiter.php
- http://php.net/manual/en/function.session-name.php
There are 5 PHP functions for session module alone. Some of them include
runtime check, but
these checks can be done with PHP_INI_MH() by using state parameter. In
fact, runtime
check should be done in PHP_INI_MH() to avoid bugs.
Use of ini_set/get() has following pros and cons
Pros
- Less API, hence simpler API.
- Modules will be less buggy.
i.e. PHP_INI_MH() must handle "state" properly, but it tends to be
forgotten, 3rd party modules especially. - Consistent coding style/API across modules, both internal and script.
- Reduced documentations. INI descriptions are only in INI section.
- Less documentations, hence less documentation bugs.
- Better documentation. All user needs to know will be in INI section.
- Awareness of INI setting use. Users are better to know they are using
INI. i.e. All INI values has the same limitations,
INI_SYSTEM/INI_PERDIR/INI_USER, stage limitations if any. - (Please point it out more advantages)
Cons
- Existing code modifications. (It's E_DEPRECATED. User may ignore.)
- (Please point it out more disadvantages)
Comments are appreciated.
Regards,
P.S. Enum for PHP_INI_MH() "stage" parameter type is better in PHP7. IMO.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi all,
I would like to propose INI set/get function deprecation, raise
E_DEPRECATED,
and make PHP_INI_MH() use the CODING_STANDARDS.For example, session module has following INI set/get functions
- http://php.net/manual/en/function.session-save-path.php
- http://php.net/manual/en/function.session-module-name.php
- http://php.net/manual/en/function.session-cache-expire.php
- http://php.net/manual/en/function.session-cache-limiter.php
- http://php.net/manual/en/function.session-name.php
There are 5 PHP functions for session module alone. Some of them include
runtime check, but
these checks can be done with PHP_INI_MH() by using state parameter. In
fact, runtime
check should be done in PHP_INI_MH() to avoid bugs.Use of ini_set/get() has following pros and cons
Pros
- Less API, hence simpler API.
- Modules will be less buggy.
i.e. PHP_INI_MH() must handle "state" properly, but it tends to be
forgotten, 3rd party modules especially.- Consistent coding style/API across modules, both internal and script.
- Reduced documentations. INI descriptions are only in INI section.
- Less documentations, hence less documentation bugs.
- Better documentation. All user needs to know will be in INI section.
- Awareness of INI setting use. Users are better to know they are using
INI. i.e. All INI values has the same limitations,
INI_SYSTEM/INI_PERDIR/INI_USER, stage limitations if any.- (Please point it out more advantages)
Cons
- Existing code modifications. (It's E_DEPRECATED. User may ignore.)
- (Please point it out more disadvantages)
Comments are appreciated.
Regards,
P.S. Enum for PHP_INI_MH() "stage" parameter type is better in PHP7. IMO.
Since there isn't comment, I guess everyone on this list agree this
proposal.
Shall I start writing this RFC?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hello,
2015-01-27 3:20 GMT+01:00 Yasuo Ohgaki yohgaki@ohgaki.net:
Hi all,
I would like to propose INI set/get function deprecation, raise
E_DEPRECATED,
and make PHP_INI_MH() use the CODING_STANDARDS.For example, session module has following INI set/get functions
- http://php.net/manual/en/function.session-save-path.php
- http://php.net/manual/en/function.session-module-name.php
- http://php.net/manual/en/function.session-cache-expire.php
- http://php.net/manual/en/function.session-cache-limiter.php
- http://php.net/manual/en/function.session-name.php
There are 5 PHP functions for session module alone. Some of them include
runtime check, but
these checks can be done with PHP_INI_MH() by using state parameter. In
fact, runtime
check should be done in PHP_INI_MH() to avoid bugs.Use of ini_set/get() has following pros and cons
Pros
- Less API, hence simpler API.
- Modules will be less buggy.
i.e. PHP_INI_MH() must handle "state" properly, but it tends to be
forgotten, 3rd party modules especially.- Consistent coding style/API across modules, both internal and script.
- Reduced documentations. INI descriptions are only in INI section.
- Less documentations, hence less documentation bugs.
- Better documentation. All user needs to know will be in INI section.
- Awareness of INI setting use. Users are better to know they are using
INI. i.e. All INI values has the same limitations,
INI_SYSTEM/INI_PERDIR/INI_USER, stage limitations if any.- (Please point it out more advantages)
Cons
- Existing code modifications. (It's E_DEPRECATED. User may ignore.)
- (Please point it out more disadvantages)
Comments are appreciated.
Regards,
P.S. Enum for PHP_INI_MH() "stage" parameter type is better in PHP7. IMO.
Since there isn't comment, I guess everyone on this list agree this
proposal.Shall I start writing this RFC?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
This would also deprecate following functions?
http://php.net/manual/en/function.gc-enable.php
http://php.net/manual/en/function.set-include-path.php
http://php.net/manual/en/function.set-time-limit.php
http://php.net/manual/en/function.error-reporting.php
Hi Martin,
On Tue, Jan 27, 2015 at 5:41 PM, Martin Keckeis martin.keckeis1@gmail.com
wrote:
This would also deprecate following functions?
http://php.net/manual/en/function.gc-enable.php
http://php.net/manual/en/function.set-include-path.php
http://php.net/manual/en/function.set-time-limit.php
http://php.net/manual/en/function.error-reporting.php
I suppose so, but we may have some exceptions.
There will be many others. I haven't count all of them yet.
Other examples are
http://php.net/manual/en/function.mb-internal-encoding.php
http://php.net/manual/en/function.mb-detect-order.php
http://php.net/manual/en/function.mb-language.php
http://php.net/manual/en/function.iconv-set-encoding.php
mb_internal_encoding() and iconv_set_encoding() will be deprecated
functions, though.
Global encoding setting should be used as the RFC that removes module own
encoding
setting passed. I'll make them to set/get global encoding setting as well
as add E_DEPRECATED
errors.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi!
Cons
- Existing code modifications. (It's E_DEPRECATED. User may ignore.)
- (Please point it out more disadvantages)
I think removing or disrupting functions without a very good reason
(such as, functionality going away or this function is abused or is
broken in many use cases) is wrong. These functions don't seem broken,
they just do something that you can do in another way. I don't think it
is necessary to deprecated them.
--
Stas Malyshev
smalyshev@gmail.com
Hi!
Cons
- Existing code modifications. (It's E_DEPRECATED. User may ignore.)
- (Please point it out more disadvantages)
I think removing or disrupting functions without a very good reason
(such as, functionality going away or this function is abused or is
broken in many use cases) is wrong. These functions don't seem broken,
they just do something that you can do in another way. I don't think it
is necessary to deprecated them.
I share the same mindset as Stas.
Let's work on resolving bugs instead of breaking BC ? :)
--
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
On Wed, Jan 28, 2015 at 4:48 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:
Cons
- Existing code modifications. (It's E_DEPRECATED. User may ignore.)
- (Please point it out more disadvantages)
I think removing or disrupting functions without a very good reason
(such as, functionality going away or this function is abused or is
broken in many use cases) is wrong. These functions don't seem broken,
they just do something that you can do in another way. I don't think it
is necessary to deprecated them.
I was about to add more of these functions for consistency indeed. e.g.
session_set_serialize_handler()
I changed my mind after discussion with Andrey. He insisted ini_set/get()
provides more consistency
and user friendliness. And I agreed with him.
There may be people like me and PHP may not need more simple ini_set/get()
copy functions.
What do you think about CODING_STANDARD part?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net