There's also a fourth approach that does not involve any changes to
PHP: autoload + eval.
When PHP is looking for your class, in your autoload you load the
values from config, generate the class source and eval() it.

The problem with using constants is that the value is still hardcoded
and if we later want to change to pulling the data from a config file
we have to change all the code that uses those constants. 

It's possible to work around this by using a unique constant name
and define('unique_name', $dynamicExpression)
(and const MY_CLASS_CONST = \unique_name;)

Maybe php could add something along these lines:

local const X = sprintf('In %s', $dynamicValue);
// Not supported in functions or loops.
// Translates internally to:
// if (defined('some_globally_unique_constant123af') ||
// !define('some_globally_unique_constant123af', X)) { throw ...; }
// use some_globally_unique_constant123af as X;
class MyClass {
const PUBLIC = X;
}

• php still needs to prevent recursion such as
  const A = count(B); const B = array_fill(1, A, 'value');,
  which is why the simplest approach would be one that eagerly evaluates dynamic expressions.
  That's probably not the only way - maybe it could track all of the constants that
  are in the process of being defined and cause an uncatchable fatal error if there was recursion.
• Right now, reading the value of a class constant can already emit notices or throw an Error (undeclared constants)
  the first time it gets evaluated
• Any approach should throw for results that contain cycles, objects, or references,
  the same way define() warns.

The below ugly proof of concept shows that the php runtime can in a sense
defer evaluation of dynamic class constants to runtime (not recursively)
(assume errstr/errfile control what constant gets loaded).
This POC should not be used anywhere.

<?php
set_error_handler(function ($errno, $errstr) {
echo "Ignoring $errno: $errstr\n";
define(
'SOME_GLOBALLY_UNIQUE_CONSTANT',
sprintf('Hello, %s', $GLOBALS['globalVar'])
);
});
class MyTest {
const KEY = 'myKey';
const FOO = [
self::KEY => [[][0], SOME_GLOBALLY_UNIQUE_CONSTANT][1],
];
}
$globalVar = 'world';
echo "Fetching MyTest::FOO\n";
var_dump(MyTest::FOO);
/*
Output:
Fetching MyTest::FOO
Ignoring 8: Undefined offset: 0
array(1) {
["myKey"]=>
string(12) "Hello, world"
}
*/

I have a work in progress wrapper for allowing const-like syntax for global constants static const X = $dynamicExpression;.
This can be seen in https://github.com/TysonAndre/php-src/pull/10
This is basically a wrapper around if (!defined(...)) { define(...); }
If anyone's planning to implement changes to the way constants can be declared,
then the POC might be worth looking at (e.g. to see what parts of the code would need to be changed),
even if their design and approach is different.

• The issues this solves has overlap and differences with what Mike Schinkel requests here.
  It's intended as a solution to limitations in different use cases that I've encountered/thought about (which this thread reminded me of).

  Notably, this deliberately can't refer to other dynamic "static const" values that haven't been declared.

• This deliberately limits it to the top-level statements in files

• Class constants below the global 'static const' can then use the eagerly evaluated const.

Reasons for me to implement the proof of concept this way:

• defined()/define() is already supported by the engine.
  This is a slight improvement due to shorter syntax,
  and being more certain the const is only set or used in one file.

• Eagerly initialized dynamic constants are easier to reason about in some ways (e.g. fetching the constant of an already fetched class is less likely to cause pauses or exceptions.)
  This makes un-noticed errors in rare code paths less likely.

• Attempting to support function calls, property accesses, class constant accesses (e.g. inherited), and variables in class constants recursively and/or lazily
  would probably break a lot of code/assumptions in the php engine.

  I might be mistaken about that, though - I'd be glad if it turned out to be easy to implement.

Declaring 'static const' as a top level statement of a function/closure/method might also be possible, but would require more work.

It's also worth mentioning that some expressions that definitely have constant values
can't be written (in a convenient way) because they use syntax that is prevented right now, such as function calls, closures, etc.

My preference would be to make it easier to use dynamic expressions, and recommend in coding guidelines that
certain types of expressions "SHOULD NOT" be used for constants that vary on a particular host.
(network calls, time, etc)

const DEFAULT_PAYLOAD = json_encode(['key' => 'value']);
const ALLOWED_ELEMENT_TYPES = array_merge(self::FIRST_TYPES, self::SECOND_TYPES);
const ELEMENT_LENGTHS = array_map('strlen', self::ELEMENTS);

For derive-once global constants, you may be looking for define.
That's a runtime operation and effectively boils down to a set-once global.
It doesn't help with constants defined in a class,
but for an already-global constant define already gives you a one-time set operation,
just not on-demand.

This POC adds an alternate syntax for a set-once global.
It prevents accidentally reusing the same global name in multiple files (e.g. with copy and paste),
and lets people looking at it know the constant is only used in that file.

 Another use-case that just occurred to me is to support testing:

class Api {
const URL: string{
return $_ENV['EXAMPLE_API_URL'] ?? 'https://api.example.com';
}
}

That example would be written with the POC as:

static const API_URL = $_ENV['EXAMPLE_API_URL'] ?? 'https://api.example.com';

class Api {
const URL = API_URL;
}

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

<sigh> So much to unpack here, but I will just hit the most important points.

snip

Symfony — which many PHP developers hold in high regard including
Drupal developers — uses constants:

Just an FYI: I assume you mention Drupal specifically here because of my history with the project. What Drupal developers hold in high regard matters not even 0% for me at this point; "Drupal does it" is not an argument that will carry any weight with me.

snip

I think this analysis proves many PHP developers do use constants in
ways you claim you would never. IOW, the use-cases I am trying to
address exist to a significant degree in the wild.

Further I believe I have made the case that there would be significant
value in allowing developers who previously used constants because of
prior lack of skill or too-tight timelines to be able to evolve their
code to initialize their constants with code instead of forcing their
users to change their code or worse.

-Mike

I think you are overstating my case. I am not arguing that one should never use constants. In fact, a majority of the examples you cite I would say are reasonable uses of constants, at least in concept. (I cannot speak to the particulars of the individual code bases.)

I am saying that the behavior of a constant is that it is... constant. A proper constant is evaluated at compile time and appears as a literal in the final runtime code, with no dereferencing. AIUI, const in PHP does exactly that, in contrast to define. That is fundamentally conceptually incompatible with a value that is derived at runtime and happens to use constant-style syntax. I am firmly opposed in principle to having a language construct that looks like a constant and makes you think it's a constant but is actually a method call that does who knows what.

There's really two different use cases here, I think, that we're conflating. ("We" meaning I think we're all doing it to an extent.)

1. I want an approximately global value that is auto-memoized on first usage, so I can access it from anywhere without having to recompute it or do the work of memoizing it myself.

2. I have a code base with lots of constants, and I've changed my mind about the API (for whatever reason) and want them to no longer be constant but runtime defined.

For point 1, I'd love it if we had some way to auto-memoize a result. That would be sweet. There's a couple of ways we could go about it... but I firmly believe that sticking it behind a const-like API is the wrong way to do it for the reasons above. (I wouldn't want to limit it to global-ish things, either, because global-ish things are, as stated, bad in every way and should be avoided whenever possible. Yes, I know there's a lot of bad code out there already with it; that doesn't mean encouraging it.)

For point 2... if you want to change your API, then your API is going to change. That's what it means to change an API. It's no different than deciding to rename a method or class. It may or may not be hard depending on the API and the install base, but that it's a constant doesn't change matters. Making code easier to refactor is all well and good, but not if it violates all expectations around what a constant is.

For derive-once global constants, you may be looking for define. That's a runtime operation and effectively boils down to a set-once global. It doesn't help with constants defined in a class, but for an already-global constant define already gives you a one-time set operation, just not on-demand. That's probably the better avenue to pursue for option 2, though again it's not one that I find worth compromising the language design for.

--Larry Garfield

Add in the "initialise on first read", and you end up with 4 lines per pseudo-constant vs 5 per method:
But then you give an example which exaggerates in the other direction.

No, I gave an example of exactly what it would like if I wrote it: one
line methods with one line docblocks, or one line constants with one
line docblocks. The only difference in your example below is that you've
omitted the docblocks from both versions, saving one line on each.

class Environments {
const PRODUCTION = 'master';
const STAGING = 'stage';
const TESTING = 'test';
const DEVELOPMENT = 'dev';
}

vs.

class Environments {
static function PRODUCTION() {
return 'master';
}
static function STAGING() {
return 'stage';
}
static function TESTING() {
return 'test';
}
static function DEVELOPMENT() {
return 'dev';
}
}

This is a really terrible example, because it's basically an enum, and
would never be anything other than a set of true constants. In a sense,
that's nitpicking at the example, but I think it's teling: the kinds of
constants that are "scannable" are generally not the kind that would be
replaced by configuration in the way you're suggesting.

That is, if you have:

class API {
    const TEST_URL = 'https://testing.api.example.com';
    const LIVE_URL = 'https://production.api.example.com';
}

...then these are nicely "scannable", but already capture the fact that
there are different options to choose from.

If instead you have:

class API {
    const URL = 'https://production.api.example.com';
    const VERSION = 1.5;
}

...then being "scannable" isn't particularly relevant, because these are
completely separate values.

What I am asking for is the ability to evolve code over time and not force code to forever retain its technical debt simply because of initial choices.

And not just for constants, but for evolvability of all code. To me that seems like such a no-brainer best practice for programming language design that I am struggling to understand the fundamental objections to it.

I suppose it would be possible to design a language which maximised
"evolvability" by using interchangeable syntax for different concepts.
For instance, properties and constants could all just be special method
calls; perhaps "const FOO=42" would be sugar for "static function FOO()
{ return 42; }" and "SomeClass::FOO" would always be the same as
"SomeClass::FOO()".

However, there will always be new requirements that require a breaking
change. For instance, maybe you need to send some API calls to one URL
and some to another, so everywhere that fetches the URL needs to choose
between two constants, or pass a parameter to the method. Or maybe you
write something as static and later wish you'd required an instance to
be constructed.

So it's not enough to say "everything should be evolvable", we need to
ask whether this specific scenario is common enough to design the
language around, and what the possible downsides of the feature might be.

The fact constants are limited to literal code is merely a limitation
of the opcode compiler, not a conceptual difference. In both cases
they are initialized before use, and then never changed. If they are
immutable once initialized, then they are conceptually constants.

I disagree, I think constants being a literal value is a design
decision, not an implementation one. Off the top of my head, I can think
of three types of things that you might call "constants":

1. A value that will never change, and you just want to give a name to.
   For instance, MINUTES_IN_HOUR=60
2. A value set at compile-time, to hard-code a particular condition. For
   instance, DEBUG=false
3. A value which is set at run-time, but happens not to change during
   the course of the application, so should not be over-written.

PHP's constants are designed primarily to be type 1 - they are literal
values, hard-coded in the source. Unlike C, there is no standard
pre-processor for PHP, so type 2 is rarer, but it's possible to
implement by manipulating the source file before deployment, or even
when running the autoloader.

Your proposed feature changes constants to instead be type 3, which I
think is a fundamentally different concept - much more like a property
with extra restrictions. I think it would be very confusing for the
syntax which everyone is used to meaning "hard-coded or at most
compile-time value" could now actually mean "global value different on
every request":

const USER_ID {
    return $_GET['user_id'];
}

Yet another approach would be for me to ask for would be for a shortened function declaration syntax. But again that would also not empower existing constants to evolve:

class Environments {
function PRODUCTION = 'master';
function STAGING = 'stage';
function TESTING = 'test';
function DEVELOPMENT = 'dev';
}

During the discussion of short closures a suggestion came up that the
syntax could be reused for single-expression methods, so you'd write this:

class Environments {
   public static fn getUrl() => 'https://api.example.com';
}

As you say, that still requires callers to know that they're calling a
method, not referencing a constant; we evidently disagree on whether
that's a good thing.

Both you and Larry have redefined my use-case to an idealogically
convenient use-case. Can we please address the use-case as I am
defining it: existing code that already uses constants and future code
where developers use constants because of lack of skill, awareness of
"best practices", or too-tight timelines?

For my part, I tried to look at the bigger picture, because I think
major changes to the language should address as many use cases as
possible, not introduce special syntax for narrow scenarios.

As Larry mentions, the proposal is also limited by "globalness". Since
constants are always static, the initialisation code can only access
global and static state, so you can't inject a configuration object into
your constructor then use it to initialise constants. And since they're
write-once, you can't use them for Laravel-style "facades", where the
access is static, but can be swapped out at run-time.

Perhaps a better angle to look at is something like the C Pre-Processor

• manipulating the code at compile-time so that multiple different
  versions of the code can be created from the same source, but constants
  are still constant at run-time. I know there are tools out there already
  to do this, but have never used one.

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

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]

Sorry, I don't see it that way. To my mind, the universal use case here is
"initialise some value once and then access it from the program"; the
syntax is secondary to that.

Evidently, you see those priorities differently; I don't think we're ever
going to agree on that.

Your "disagreement" has the effect of either ignoring or dismissing the use-case that was the primary motivation for me to make this request.

If you want to dismiss my use-case at least please do so explicitly.

What aspects am I dismissing? I absolutely agree that an equivalent to
Java's final variables would implement your use case - if you were willing
to relax your syntax constraint. But your proposal is not to have immutable
variables, as you've said yourself.

You ask me to explore what other languages do. I explain that Java use static final to create constants which you can declare them dynamically.

You then claim that since constants are declared as final variables they are variables. Which is true, but they are also dynamically initialized constants. But then redirect to discussing PHP variables, which unlike Java have incompatible syntax to variables and thus cannot address my primary use-case.

Basically you asked me to give an example where constants are dynamically initialized, so I did, and then you claim those are just finalized variables. Which they are. But they are also dynamically initialized constants. Conceptually the difference is academic.

If I gave you an example of a compile time constant than it would be equivalent to PHP and unable to be initialized dynamically. If I gave you an example of a dynamically-initialized constant then yes, it is going to be a finalize variable. So effectively you set a trap for me that I could not satisfy, a catch-22.

Would you have accepted my example as evidence of other languages having dynamically-initialized constants instead if Java had used the const keyword instead of using static final keyword, but with identical implementation? Or will you only accept compile time constants as an example, which by definition disallow initialization?

See the catch-22, and hence the distinction without a difference?

See my my earlier comment about implementation - I'm not sure how we'd
define valid values so that they definitely couldn't be mutable. You could
restrict to just scalars, but that would then be a tighter restriction than
actual constants - "const A = [1,2,3];" is valid right now,

Currently this does not work, so I do not see where the problem is:

class Foo {
const BAR = [ 1,2,3 ];
}
Foo::BAR[0] = 9; // PHP Fatal error: Cannot use temporary expression in write context

so preventing that being set dynamically would feel odd.

Did not propose that.

You can currently initialize const to an array now, and const arrays are currently immutable. That would not need to change.

Further, we continue to disallow initializing const to objects, even dynamically. No change there.

So where is the issue?

Perhaps I'm using the wrong terminology,

Probably, at least for me. For decades I have know "pre-processor" to mean textual substitution. Maybe the newer hipster developers have redefined that term to mean something else, but I when I hear "pre-processor" I just think of pattern replacement in text.

(Note I am just being tongue-in-cheek about "hipster." No real insult is intended. :-)

but I think we're talking about the same thing: something that runs before the
main program, which takes certain parts of the code, interprets them in some
way, and combines them with the rest of the program.

In that context, I am open.

So: an interpreter that runs during preloading, which takes special blocks of code,
runs them as PHP, and then combines the results into the AST/OpCode
representation of the program.

That actually sounds like the brilliant suggestion from Robert Hickman to consider the equivalent of compile-time code from the Jai programming language. If you have not watched these — which I included again from Hickman's email — I urge you to watch them as how Jai works with it's compile-time code execution really is brilliant:

• https://www.youtube.com/watch?v=UTqZNujQOlA. // Starting at 39:20
• https://www.youtube.com/watch?v=59lKAlb6cRg

I stand by my comment that this has some of the same problems as a
separate "build" script, such as the need to be configured correctly,

I find repeating of this as overstating the concern simply because any programming language feature would need to be used correctly. So this also feels like a distinction without a difference.

the difficulty of debugging errors in this special code,

Depends? If this where to use XDEBUG just like regular PHP there would be zero difference.

and the need to invoke the extra processing manually for things like command-line scripts.

Since PHP is different from a pre-compiled language like C or Go, it compiles "on-demand." So I would see zero need for a build step.

I would also see PHP could first run the compile-time code once, and then run the runtime code for every execution. On-demand. And XDEBUG could be used for both.

For CLI, it might always run the runtime code and then the compile time code. Unless there is a standard location set of compiled opcode in .ini file, and/or unless PHP provided ways to generate OpCode artifacts to be loaded at runtime.

-Mike