On Wed, 8 Jan 2020 at 20:28, Mike Schinkel <m...@newclarity.net> wrote:
> > On Jan 8, 2020, at 5:48 AM, Rowan Tommins <rowan.coll...@gmail.com> > wrote: > > > > I think immutable variables very much address the use cases you're trying > > to address, except for the additional requirement about which syntax > access > > should use. > > In the USA we have a saying: "Besides that Mrs. Lincoln, how was the play?" > 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. > > That's a really significant difference, because it > > means that they inherit all the behaviours and syntax of variables, which > > PHP's constants currently do not. > > Sorry, but this just feels to me you are arguing the aspects that support > your argument that PHP constants can't change, but dismissing the aspects > that do not support said arguments. > 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. > There is no reason this would _have_ to support objects. The use-case I am > bring up in my experience in ~90% string, ~10% numbers. > 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, so preventing that being set dynamically would feel odd. > I was suggesting the ability to run some code that would only run once > until the server is restarted or manually flushed in code rather than every > page load. > Perhaps I'm using the wrong terminology, 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. 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. 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, the difficulty of debugging errors in this special code, and the need to invoke the extra processing manually for things like command-line scripts. Regards, -- Rowan Tommins [IMSoP]
