Hi,
I wanted to ask what's our current consensus about feature requests like
this: https://bugs.php.net/bug.php?id=67309
The requested function wouldn't provide anything which isn't currently
available via ini_get(), but it would be a bit natural to expect a get
method where a set exists.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi,
I wanted to ask what's our current consensus about feature requests like
this: https://bugs.php.net/bug.php?id=67309
The requested function wouldn't provide anything which isn't currently
available viaini_get(), but it would be a bit natural to expect a get
method where a set exists.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi,
We talked about this with Yasuo in regards to some ext/session stuff
(although it was about setters) and agreed on keeping ini_set() only.
He even wrote a quick RFC about it:
https://wiki.php.net/rfc/deprecate-ini-functions
My opinion in general is that we don't need functions that duplicate
ini_set(), ini_get() for a particular setting and existing ones should
be removed in the future instead of adding more to complement them. No
idea what other people think about it though.
Cheers,
Andrey.
Hi,
I wanted to ask what's our current consensus about feature requests like
this: https://bugs.php.net/bug.php?id=67309
The requested function wouldn't provide anything which isn't currently
available viaini_get(), but it would be a bit natural to expect a get
method where a set exists.--
Ferenc Kovács
@Tyr43l - http://tyrael.huHi,
We talked about this with Yasuo in regards to some ext/session stuff
(although it was about setters) and agreed on keepingini_set()only.
He even wrote a quick RFC about it:
https://wiki.php.net/rfc/deprecate-ini-functions
Yeah, but AFAIR we didn't come up with an agreement (other than reverting
out a couple of new functions from PHP 5.6.0).
My opinion in general is that we don't need functions that duplicate
ini_set(),ini_get()for a particular setting and existing ones should
be removed in the future instead of adding more to complement them. No
idea what other people think about it though.
I agree that providing multiple ways to achive the same thing is not really
useful.
But we also have to decide whether or not it is worth the BC to remove some
existing function only because one can already do the same thing via
ini_set.
Another (albeit maybe a bit far-fetched) aspect is that somebody could
assume that he/she can restrict a setting via disabling the appropriate
function(via disable_functions) while that can be bypassed through the
ini_set or vica versa.
So the more ways we provide for the same setting to be set it is more
likely that somebody forgets protecting one of those.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi,
Hi,
I wanted to ask what's our current consensus about feature requests like
this: https://bugs.php.net/bug.php?id=67309
The requested function wouldn't provide anything which isn't currently
available viaini_get(), but it would be a bit natural to expect a get
method where a set exists.--
Ferenc Kovács
@Tyr43l - http://tyrael.huHi,
We talked about this with Yasuo in regards to some ext/session stuff
(although it was about setters) and agreed on keepingini_set()only.
He even wrote a quick RFC about it:
https://wiki.php.net/rfc/deprecate-ini-functionsYeah, but AFAIR we didn't come up with an agreement (other than reverting
out a couple of new functions from PHP 5.6.0).
We didn't indeed, I was just giving you partial feedback. :)
My opinion in general is that we don't need functions that duplicate
ini_set(),ini_get()for a particular setting and existing ones should
be removed in the future instead of adding more to complement them. No
idea what other people think about it though.I agree that providing multiple ways to achive the same thing is not really
useful.
But we also have to decide whether or not it is worth the BC to remove some
existing function only because one can already do the same thing via
ini_set.
With work supposedly being started on PHP6, now is the right time to
make that decision. :)
Another (albeit maybe a bit far-fetched) aspect is that somebody could
assume that he/she can restrict a setting via disabling the appropriate
function(via disable_functions) while that can be bypassed through the
ini_set or vica versa.
So the more ways we provide for the same setting to be set it is more likely
that somebody forgets protecting one of those.
Exactly.
Cheers,
Andrey.
Hi,
On Tue, Jun 3, 2014 at 10:41 AM, Ferenc Kovacs tyra3l@gmail.com
wrote:Hi,
I wanted to ask what's our current consensus about feature requests
like
this: https://bugs.php.net/bug.php?id=67309
The requested function wouldn't provide anything which isn't currently
available viaini_get(), but it would be a bit natural to expect a get
method where a set exists.--
Ferenc Kovács
@Tyr43l - http://tyrael.huHi,
We talked about this with Yasuo in regards to some ext/session stuff
(although it was about setters) and agreed on keepingini_set()only.
He even wrote a quick RFC about it:
https://wiki.php.net/rfc/deprecate-ini-functionsYeah, but AFAIR we didn't come up with an agreement (other than reverting
out a couple of new functions from PHP 5.6.0).We didn't indeed, I was just giving you partial feedback. :)
My opinion in general is that we don't need functions that duplicate
ini_set(),ini_get()for a particular setting and existing ones should
be removed in the future instead of adding more to complement them. No
idea what other people think about it though.I agree that providing multiple ways to achive the same thing is not
really
useful.
But we also have to decide whether or not it is worth the BC to remove
some
existing function only because one can already do the same thing via
ini_set.With work supposedly being started on PHP6, now is the right time to
make that decision. :)Another (albeit maybe a bit far-fetched) aspect is that somebody could
assume that he/she can restrict a setting via disabling the appropriate
function(via disable_functions) while that can be bypassed through the
ini_set or vica versa.
So the more ways we provide for the same setting to be set it is more
likely
that somebody forgets protecting one of those.Exactly.
Cheers,
Andrey.
resurrecting this thread in the hope of getting a bit more feedback.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi!
resurrecting this thread in the hope of getting a bit more feedback.
About removing functions - I don't really see any particular win in it.
I mean, we'd have enough BC concerns in PHP 7 without having to worry
about missing functions that didn't hurt anybody. However, it may be
fine to add a note in the manual saying "please use ini_*, it's better
style" or something like that.
About adding getter for execution time - not sure if there's any
practical need for it, though I wouldn't lose sleep if it were added :)
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi,
Hi!
resurrecting this thread in the hope of getting a bit more feedback.
About removing functions - I don't really see any particular win in it.
I mean, we'd have enough BC concerns in PHP 7 without having to worry
about missing functions that didn't hurt anybody. However, it may be
fine to add a note in the manual saying "please use ini_*, it's better
style" or something like that.
My suggestion was to deprecate them first, which isn't much different
to adding a doc note that ini_*() is better.
Cheers,
Andrey.