Re: RFC: autoconst
| From: | Pierre | Date: | Mon, 02 Aug 2021 07:36:46 +0000 |
| Subject: | Re: RFC: autoconst | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115623@lists.php.net to get a copy of this message | ||
Le 01/08/2021 à 17:59, Serhii Smirnov a écrit
I was more interested in autoconst keyword that reduces copy/pasting constant name as it's value. camelcase and snakecase is an addition. A real example why I wanted to use autoconst: on the past project, we had class that holds constants with the feature flag names. Something like: class Features {Hello, Having an implicit by-convention name reducing algorithm from constant string seems very obfuscated and dangerous, especially for a preference name. This means that if you fix a typo anywhere, it'll implicitly change the underlying acceptable value for anywhere your configuration comes from (env var, database, configuration file, ...). This means that will create a maintenance burden for anyone using such autoconst this way. The right way to handle those situation is not by writing less code, but by writing more, you should explicitly map your preference names over in-code constants, any attempt in doing otherwise will cause you trouble at some point later in time. So I don't think this is a good example, in my opinion this is more an school use-case example of what you should never do ! Regards, -- Pierreconst FEATURE_FLAG_WITH_SOME_LONG_NAME = 'feature_flag_with_some_long_name'; const FEATURE_SOME_ANOTHER_COOL_FEATURE = 'feature_some_another_cool_feature';} later, in the code we had to check if certain feature is enabled in the system: if ($featureManager->isEnabled(Features::FEATURE_FLAG_WITH_SOME_LONG_NAME)) {// some feature related code goes here} The class Features could be written as: class Features {autoconst lower FEATURE_FLAG_WITH_SOME_LONG_NAME, FEATURE_SOME_ANOTHER_COOL_FEATURE;}