Re: Initializing constants once, with code?

> On Jan 9, 2020, at 4:38 AM, Rowan Tommins <rowan.collins@gmail.com> wrote: > 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