Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107982
User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1
Mime-Version: 1.0
Message-ID: <70cbf5ab-2445-4003-987e-cb26301d64de@www.fastmail.com>
In-Reply-To: <D56361F6-8B11-4363-908D-962F683936BF@newclarity.net>
References: <5e0d723f.1c69fb81.e2ae8.24e2SMTPIN_ADDED_MISSING@mx.google.com>
 <74F2DBFC-E63C-428C-A37F-2D0CEE15AD0F@newclarity.net>
 <DM5PR07MB30676FC66DA036895D5E3554F9200@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CD014984-715D-49C5-9A90-66C0A11F9818@newclarity.net>
 <c40a96fe-8929-4b44-98bd-3370a12ec516@www.fastmail.com>
 <D56361F6-8B11-4363-908D-962F683936BF@newclarity.net>
Date: Fri, 03 Jan 2020 13:52:43 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jan 3, 2020, at 12:55 PM, Mike Schinkel wrote:
> 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

There's two broad reasons I think this is a bad idea.

1) Constants are one thing.  Function calls are another.  They serve different purposes.  Trying to mutate them into one thing can only lead to confusion and lack of understanding about what is actually going on.

2) The approach you describe (of starting with constants everywhere and refactoring to method calls later)... I would never do and do not endorse.  What you describe is basically "make globals nicer to work with", whereas I am 100% firmly in the camp of "if I could remove globals from the language entirely I would".  Frankly, the use of constants for configuration is an anti-pattern to begin with; they should be used only for things that are truly constant.  Honestly, I cannot recall the last time I used constants for anything other than giving some other compile-time value a nicer name.  (Eg, DEFAULT_THING_VALUE or giving nice names to bit flags or something like that.)

For configuration, my answer is frankly "put your configuration behind a nice configuration object from the very beginning and then you won't have to refactor it later; Problem solved."  You can use env vars for configuration, and wrap those into a nice object, possibly using one of the many DotEnv implementations that already exist to make them nicer to work with in development.  That is superior in basically every conceivable way to semi-mutable globals passing themselves off as pseudo-constants.

I *would* love to see property accessors come back, which would have a side effect of making what you describe a little easier, but at no point is it pretending to be a compile time value when it isn't.

--Larry Garfield