Hi Larry,

Thanks for replying.

>  It seems to me it would be much cleaner to just... build that into a static 
> method call with the derivation-and-caching logic behind the scenes.  It's 
> not complicated code.

That is exactly what I have been doing, and what I am finding suboptimal.

The problem is that, most of the time and especially when refactoring poorly 
written code, we just want a constant.  One line in the class file, hard coded. 
 

We ideally don't want to have to write a full functionr.  So for five data 
elements, 5 easy to read lines of code with constants vs. 20 harder to read 
lines with functions, or at least 40 lines if we include PHPDoc for those 
functions, which is part of our standard for writing functions.

When we *later* want to be able to refactor to initialize with code we want to 
do so w/o having to modify the code that is already using the constants. But we 
many never actually need to do so. What I am asking for is the option.

Basically, in my view, a programming language is better if it can support 
refactoring a reusable unit of code to add additional functionality W/O 
requiring the code that uses the reusable element to be modified.  Using your 
proposed approach we cannot start using constants and later move to functions 
unless we modify all code that uses those constants. That is Bad JuJu(tm) in my 
book.

OTOH, if PHP 8.x would allow functions w/o parameters to be called w/o 
parenthesis then your approach satisfy the use-case:

class Stuff {
    protected $val;

    public static function VAL() {
         self::$val ??= computeStuff();
         return self::$val;
    }
}
echo Stuff::VAL;   //<== if this could work then using functions would address 
the use-case.

> I agree with the use case, but not with the solution of piggybacking them 
> onto constants. 

Let me put it more concretely.  What I am asking for is this:

> "Transitionally of reusable code when using constants that does not require 
> modifying code that already uses the constant."

So using functions does not actually address the use-case I am identifying.

Is there some technical reason why you object to extending constants, or is it 
your objection more stylistic?

-Mike



Reply via email to