# Deprecating all INI set/get functions and use ini_set/get() - Thread: https://externals.io/message/81099 - Original archive: https://news-web.php.net/php.internals/81099 - Started by Yasuo Ohgaki on 2015-01-25T00:29:52+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #81099 — Yasuo Ohgaki — 2015-01-25T00:29:52+00:00 URL: https://externals.io/message/81099#81099 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 --- ## #81191 — Yasuo Ohgaki — 2015-01-27T02:20:56+00:00 URL: https://externals.io/message/81099#81191 · In reply to: #81099 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 --- ## #81204 — Martin Keckeis — 2015-01-27T08:41:02+00:00 URL: https://externals.io/message/81099#81204 · In reply to: #81191 Hello, 2015-01-27 3:20 GMT+01:00 Yasuo Ohgaki : > Hi all, > > > > > […] > > 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 --- ## #81229 — Yasuo Ohgaki — 2015-01-27T11:13:30+00:00 URL: https://externals.io/message/81099#81229 · In reply to: #81204 Hi Martin, On Tue, Jan 27, 2015 at 5:41 PM, Martin Keckeis 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 --- ## #81256 — Stanislav Malyshev — 2015-01-27T19:48:46+00:00 URL: https://externals.io/message/81099#81256 · In reply to: #81204 Hi! > > […] 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 --- ## #81257 — Paul Dragoonis — 2015-01-27T19:53:52+00:00 URL: https://externals.io/message/81099#81257 · In reply to: #81256 > > Hi! > > > […] > > 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 --- ## #81287 — Yasuo Ohgaki — 2015-01-28T06:55:44+00:00 URL: https://externals.io/message/81099#81287 · In reply to: #81256 Hi Stas, On Wed, Jan 28, 2015 at 4:48 AM, Stanislav Malyshev wrote: > > […] > > 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