Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108015
To: internals@lists.php.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>
 <b32edf0c-451d-2281-8036-0b631a3c7a6f@gmail.com>
 <CD3AFCD7-EF2F-46C7-90D3-3A83A1D8836C@newclarity.net>
 <53556dfb-44ce-f902-204c-9a7da9484a61@gmail.com>
 <65567C7C-CF0F-4562-8943-F1F302134B07@newclarity.net>
 <f9e2f739-4964-b259-d9e5-4aeec938c54b@gmail.com>
 <F48FF1DC-5DE9-4C30-8BCF-C17A1877AF37@newclarity.net>
Message-ID: <6f20bda1-eff6-631d-915f-d6bb149ee666@gmail.com>
Date: Mon, 6 Jan 2020 21:59:29 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.3.1
MIME-Version: 1.0
In-Reply-To: <F48FF1DC-5DE9-4C30-8BCF-C17A1877AF37@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: rowan.collins@gmail.com (Rowan Tommins)

On 05/01/2020 21:53, Mike Schinkel wrote:
> Yet you called my list of URLs enums, and they are not at all arbitrary and absolutely want to change.


I apologise - I took a guess without context for how those constants 
would be used, but apparently they're something rather different.


> I take it you have never used Pantheon hosting then?  You create a named environment to match a Git branch.


I'm still struggling to understand why you need multiple constants, all 
mutable based on some other dimension. If the ultimate goal is to know 
the name and branch of the *current* environment, how do the constants help?

It seems on the face of it like the constants have outlived their 
usefulness, and need to be replaced by a lookup table of some kind.


> What is "better" in this context is one's opinion. You might not find 
> it beneficial, but I would. 


Agreed. I actually said the same in one draft reply, but maybe deleted 
it while editing down.


>> "Constants are defined at compile-time" is a status quo in the same sense as "variables can be assigned to" is a status quo - you could certainly design a language differently, but it's not just something that happened by accident, it's a design decision.
> It was a design decision in that maybe it did not occur to them that it would be useful; IOW a design by omission.


We'll just have to agree to disagree here. I stand by the assertion that 
"compile-time constants" are a well-defined feature, whose restrictions 
are part of their definition and purpose.


> Ruby has the .replace method for constants and can thus assign at runtime:
> =========
> https://stackoverflow.com/a/6712438/102699


That method is not actually a feature of constants, its abusing the fact 
that everything is an object, so the *value* of a constant might still 
be a mutable object. It's an interesting "cheat", but it's not really a 
deliberate language feature.


> C++ has const member functions (not exactly the same, but similar):
> =========
> https://www.linuxtopia.org/online_books/programming_books/thinking_in_c++/Chapter08_014.html


Unless I'm missing something, this isn't really related to anything 
we've been discussing, it just happens to use the keyword "const".


> Python adds a final qualifier to turn variables into constants. Thus is supports initializing constants:
> =========
> https://stackoverflow.com/a/47821212/102699
> http://code.activestate.com/recipes/65207-constants-in-python/


Those links seem to say that Python doesn't have constants *at all*, but 
you can emulate them in various ways. As such, you can give them pretty 
much whatever behaviour you like, since you're defining the language 
feature from scratch.


> Javascript can assign constants at runtime:
> =========
> fn = function() { return "World"; };
> const who = fn();
> alert( "Hello " + who );

This is a more interesting case; some properties to ponder:

- implemented as a special kind of variable (e.g. they have the same 
scope rules and syntax as "let" variables)
- can be global or block-scoped, but not a property of an object
- cannot be pre-declared before they are assigned, or automatically 
initialised on first reference
- can contain any value, including mutable objects


> Java creates class constants with `public static final` which can be initialized with code:
> =========
> https://www.javaworld.com/article/2076481/use-constant-types-for-safer-and-cleaner-code.html


Another interesting case:

- implemented as a special kind of variable
- can contain any value, including mutable objects
- will raise an error if the compiler cannot prove there is exactly one 
assignment; i.e. these are not purely run-time constructs like PHP's 
define() constants
- can be static members of a class, and include an inline initializer
- can be static members of a class and have no inline initializer, in 
which case they *must* be initialized using a "static initializer block" 
which will be run the first time *the class* is referenced at run time 
(a bit like substituting the value during autoloading in PHP)
- can be instance fields, and must be initialised inline, or in every 
possible constructor
- can be block-scoped variables, and must be initialised before first use

The interesting thing here is that the constants are initialised the 
same way as any other variable, not using any special on-demand code. 
Because of the language's design, the compiler is able to prove that 
they are assigned exactly once. That proof is probably a lot harder in 
PHP, and the check would probably be punted to run-time.


The biggest sticking point in my mind is your insistence that they share 
syntax with constants, rather than variables. This means they can only 
be used in static class or namespace context, not against an instance.

It also means *widening* the meaning of a construct, rather than 
*narrowing* it: the "final" keyword in Java doesn't let variables do 
anything new, it just restricts them; your proposed constant 
initialization would allow constants to act in new ways, including 
holding complex, mutable types. That's likely to cause confusion for 
both humans and tools written based on the current concept that a 
constant can always be computed at compile-time.



>> It's a limitation in the very basic sense that it limits what you can do. You can't write this, for instance:
>>
>> class API {
>>      private $config;
>>      public function __construct($config) {
>>          $this->config = $config;
>>      }
>>
>>      const URL {
>>           return $this->config->getValue('API_URL');
>>      }
>> }
> But you could do this:
>
> class Api {
>     const URL:string {
>           return Config::get()->api_url;
>      }
> }


The difference is that a Java-style "final variable" can have a single 
value *per instance*, so this is valid:

class API {
     private final $URL;
     public function __construct($config) {
         $this->URL = $this->config->getValue('API_URL');
     }
}



>> I'm just looking for solutions to your use case, which as I understand it is values which change rarely based on configuration.
> I honestly do appreciate it.  You are generally very good about that kind of thing.


I would be interested to hear more about why you think pre-processing 
doesn't suit your use case. It seems like a good fit to me:

- naturally fits with code expecting compile-time constants
- no run-time overhead if done as part of deployment
- can be implemented using succinct syntax, rather than run-time 
initialisation code


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]