Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
On 25/01/2022 19:44, Chase Peeler wrote:
If we start throwing exceptions, which can't be suppressed, it will make
this much more difficult to read since the constants.php will have to be
updated:
if(!defined('dbserver')){
define('dbserver','productiondb.example.com');
}
if(!defined('otherconstant')){
define('otherconstants','foobar');
}
A wrapper function for this use case is entirely trivial:
function define_if_not_defined($name, $value) {
if ( ! defined($name) ) {
define($name, $value);
}
}
Give it a short name like 'def', and your config file actually becomes
shorter:
def('dbserver', 'productiondb.example.com');
def('otherconstants', 'foobar');
"define" itself is just a function name, not a reserved word, so you
could even declare the above as "define" in a namespace, then add "use
function SomeNamespace\define;" and leave the rest of the file alone.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
On Tue, Jan 25, 2022 at 9:45 PM Chase Peeler wrote:
> it will make this much more difficult to read since the constants.php will
> have to be
> updated:
>
> if(!defined('dbserver')){
> define('dbserver','productiondb.example.com');
> }
> if(!defined('otherconstant')){
>define('otherconstants','foobar');
> }
You could use this form for conciseness:
```
defined('dbserver') or define('dbserver', 'productiondb.example.com');
defined('otherconstant') or define('otherconstant', 'foobar');
```
IMHO it's clearer than `@define()` as it makes it explicit where you
expect a possible previous definition and where you don't.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
On Tue, Jan 25, 2022 at 3:08 PM Kamil Tekiela wrote: > A constant is a value that, unlike a variable, cannot be reassociated with > a different value. A properly written software should never redefine > constants. The possibility of redefining constants in PHP should be > considered a bug rather than a feature. > Constants are not good for configuration values that can be changed. A > proper data structure should be used instead. Constants should never have > to be redefined, either by the software itself, its tests or its > extensions. Constant values must remain the same under all circumstances > otherwise they are no longer constants. > > Regardless of whether it's a proper use of constants or not, it's something that was in place long before I started and not something we can easily change now. Also, I'm not suggesting that we allow constants to be redefined. My setup actually works because you can't redefine them. The idea is that the local configuration file is processed first. > +1 to remove it in PHP 9.0 > -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
A constant is a value that, unlike a variable, cannot be reassociated with a different value. A properly written software should never redefine constants. The possibility of redefining constants in PHP should be considered a bug rather than a feature. Constants are not good for configuration values that can be changed. A proper data structure should be used instead. Constants should never have to be redefined, either by the software itself, its tests or its extensions. Constant values must remain the same under all circumstances otherwise they are no longer constants. +1 to remove it in PHP 9.0
Re: [PHP-DEV] [Strawpoll] Promoting redefining constant to exception
We have a main "constants.php" file that resides in git. The first line of
constants.php includes local_constants.php, which is kept out of git. The
idea is that we can "override" any of the constants on a per server basis.
constants.php:
@define('dbserver','productiondb.example.com');
local_constants.php
@define('dbserver','devdb.example.com');
If we start throwing exceptions, which can't be suppressed, it will make
this much more difficult to read since the constants.php will have to be
updated:
if(!defined('dbserver')){
define('dbserver','productiondb.example.com');
}
if(!defined('otherconstant')){
define('otherconstants','foobar');
}
On Sat, Jan 22, 2022 at 10:29 PM Mark Randall wrote:
> Internals,
>
> While cleaning up some PRs I was prompted to re-visit one I had
> outstanding about exception-throwing behaviour when redefining
> constants, this applies to functions like define and language syntax
> constructs such as const.
>
> There have been a few discussions in the past about the topic.
>
> Here is one from 2016 from Dmitry:
> https://wiki.php.net/rfc/constant_redefinition
>
> Discussion:
> https://externals.io/message/93885
>
> My own PR:
> https://github.com/php/php-src/pull/5265
>
> Since Dmitry's RFC was made in 2016, and my PR a while ago, attempted
> redeclaration was promoted from a notice to a warning, but I still think
> it's sensible to go one step further.
>
> There was mention on github that there was some resistence to promotion
> to exception in the past, but I think there is a strong possibility that
> the mood may be different many years later, with PHPs positive moves
> towards throwing on poorly defined or illogical behaviour.
>
> To gauge this, I'm throwing out a non-binding strawpoll to get the lay
> of the land before doing anything else with it. If there is general
> favour I'll fix up my patch and do a proper RFC.
>
> https://wiki.php.net/redefine_constants_exception_strawpoll
>
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
On Tue, Jan 25, 2022 at 2:47 AM Mark Randall wrote: > Let's open a discussion as to what we might want to do in the future, > and depending on how things shake out, we can decide what route to take > with regards to bringing RFCs to vote. My personal opinion: there should be no old style errors, warnings or notices. I don't want to have any more situations like "Oh, there was something wrong with your code. Hope you'll notice this in your error logs. Meanwhile, the app will just kinda limp along, likely resulting in bogus data/behavior." There should only be E_DEPRECATED for things that will change in a future release and E_ERROR for rare situations that can't be reasonably handled with exceptions (like uh, unhandled exceptions and OOM errors). Everything else should be an exception, period. -- Best regards, Max Semenik
