Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

2015-01-27 Thread Yasuo Ohgaki
Hi Stas,

On Wed, Jan 28, 2015 at 4:48 AM, Stanislav Malyshev 
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
yohg...@ohgaki.net


Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

2015-01-27 Thread Paul Dragoonis
On 27 Jan 2015 19:49, "Stanislav Malyshev"  wrote:
>
> 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
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

2015-01-27 Thread Stanislav Malyshev
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
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

2015-01-27 Thread Yasuo Ohgaki
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
yohg...@ohgaki.net


Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

2015-01-27 Thread Martin Keckeis
Hello,

2015-01-27 3:20 GMT+01:00 Yasuo Ohgaki :

> Hi all,
>
> On Sun, Jan 25, 2015 at 9:29 AM, Yasuo Ohgaki  wrote:
>
> > 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
> yohg...@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


[PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

2015-01-26 Thread Yasuo Ohgaki
Hi all,

On Sun, Jan 25, 2015 at 9:29 AM, Yasuo Ohgaki  wrote:

> 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
yohg...@ohgaki.net