> On Jan 7, 2020, at 5:15 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> It seems to me that there are two different concerns there:
> <snip>
> So at its simplest, I would write something like this:
>
> class Environments {
> const PRODUCTION = 4;
> const STAGING = 3;
> const TESTING = 2;
> const DEVELOPMENT = 1;
>
> public static $branches = [
> self::PRODUCTION => 'master',
> self:: STAGING = 'stage',
> self:: TESTING = 'test',
> self:: DEVELOPMENT = 'dev',
> ];
> }
I think you are taking one of my use-cases and over-focusing on it rather than
accepting it as just one of many applicable use-cases.
That said, I would not want to implement as you propose. I prefer to have
values that can change be declared at the top of the class as constants where
they are _not_ obscured by extra syntax — as in your example with brackets,
self::, and fat arrows — so as to make them the most scannable.
Again, those are my preferences. Yours can clearly be different. But unless the
PHP "charter" is revised to embrace "one way and only one way to accomplish a
given task" like the Zen of Python, my preference and your preferences should
be allowed equal weight.
> It's not a feature of constants, it's a feature of strings and arrays,
> because they are implemented as objects. The same trick would be possible
> in PHP if constants could have objects as values:
Even so, in Ruby you can define constants dynamically at runtime.
That said, maybe I should be requesting that PHP constants be able to have
objects, too...?
> Or maybe everybody really wishes it had them, but nobody's come up with an
> implementation that fits into the language design?
Po-ta-to, po-tah-to; a past design decision really does not matter. It is an
example of a "sunken cost."
What should only matter is what makes more sense moving forward.
> If we take these two statements really literally, you can do everything you
> want already:
Except there was a third statement you did not reference:
- "My primary goal is to be able to modify constants in _existing_ code to be
initialize at runtime to support evolvability/refactoring."
> Then all the JS and Java examples aren't going to help your argument,
> because those are most definitely immutable variables, not compile-time
> constants extended with initialisation syntax.
My argument has been and continues to be that that is a distinction without a
difference.
Besides, didn't you ask for examples and I gave you one from each of five of
the most common languages? It seems disingenuous to now try to argue the
examples I gave don't apply on reasons of technicality.
> My point was that more assumptions will break if you widen the meaning of
> "constant" than if some variables are marked immutable.
I'm all for taking those into consideration assuming we delineate them
concretely instead of just referring to them abstractly as a class of unknown
problems.
So, what real-world specific concrete problems will this "widening" cause?
> For the record, I think generators are a really neat feature, but
> absolutely hate that they are declared with the "function" keyword, and
> hate that they reuse the "return" keyword for "set final value".
>
> So, yes, that's a good example of something that breaks people's
> expectations of what keywords mean, and I think that's a bad thing.
I was not pointing out the naming, I was pointing out how confusing the
features are to understand and use regardless of naming.
But I am not arguing that we do not including confusing features. To the
contrary, I think we should include more power in the language, even in places
it might be confusing.
Just not Ruby-level power a.k.a. ability to completely redefine the language
level of power. :-D
> I'm not saying it's impossible to account for it, I'm just saying there may
> be a lot of tools out there which would need to be updated. Saying "simply"
> doesn't make it so!
That can be said about every language enhancement, so as an argument against a
feature it feels a bit contrived.
> I was thinking much more abstractly: some code of some sort that runs as a
> separate build step, and produces some kind of output that can be
> referenced cheaply at run-time.
>
> In particular, I was imagining the pre-processor being fully aware of the
> language's syntax, and operating at the AST level. You could view it as an
> extension of compiler optimisations: explicitly saying "run this before you
> even deploy to the server, the result will never change".
>
> The output to PHP is necessary for the same reason client-side languages
> are transpiled to JavaScript - it's the language spoken by the target
> run-time. If we could treat OpCodes as a stable target, like .NET CLI, or
> Java bytecode, it could target that instead, but it wouldn't actually make
> much difference to the operation of the pre-processor. There is of course a
> side-effect that the resulting PHP code can be read by a human, making it
> easier to debug.
After posting my objection to pre-processing I remembered there was another
reason I object to pre-processors that is even more significant than lack of
composibility. And my objection extends to all the transpiring being done with
Javascript and CSS too, although I put up with those because the community has
mitigated some of the worst problems and because so many developers have
embraced them.
The other objections I have to pre-processing:
1. It adds a build step to testing. PHP currently does not need a build step
and so the code-run-test cycle is not interrupted by a build step.
2. Build steps are non-trivial to set up and keep running. The front-end
developers I work with are always having some kind of problem with their build
process.
3. The source is no longer the production code. This means line numbers and
possibly other things in the error log no longer match the source code.
4. Debugging is much harder. For PHP, XDEBUG does not understand preprocessed
code.
What would be interesting instead would be to have some kind of
developer-controlled pre-loading where classes could be marked to be pre-loaded
in some way. If we had those then one potential compromise would be that
constants could only be dynamically-initialized in pre-loaded classes, which
could significantly reduce Larry and your stated objection since the
initialization would happen at preload time and not page-load time.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
