Hi Nikita,
> > At present, no. They're "just" objects, and you can't assign an object
> > to a constant. Unfortunately I'm not sure how to enable that without
> > making them not-objects, which introduces all sorts of other complexity.
>
> This should at the least be clarified in the RFC. Is this a limitation for
> constants specifically, or anything using constexpr initializers? For
> example, is writing "function foo(MyEnum $e = MyEnum::SomeDefaultCase)"
> possibly? It would be a significant limitation if it weren't.
>
> Generally, I think the limitation on objects in constants is mostly
> artificial and you should consider lifting it as part of this RFC.
> Previously you simply couldn't create an object in a constexpr initializer,
> so supporting this wasn't really relevant. With enums, this becomes
> important.
I agree it should be clarified (and have phpt tests).
Another option would be to lift the limitation on objects in constant
expression,
but only on immutable objects.
(currently just enum values)
There's a range of opinions on internals over what a constant would ideally be.
(something that is actually constant and not dependent on environment to make
code as readable as possible,
or something that does not change at runtime, etc.)
So there may be objections if the change introduces the ability to write code
like this,
but maybe more developers would find supporting only enums acceptable (continue
throwing for non-enums):
```
define(CONFIGURATION, new stdClass());
class X { const CONFIGURATION = CONFIGURATION; }
X::CONFIGURATION->endpoints = [$dynamicUrl];
// do stuff
X::CONFIGURATION->endpoints = [$otherDynamicUrl];
```
Then again, this suggestion to only support enums may also be an unsatisfying
compromise.
Regards,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
