> On Jan 9, 2020, at 4:38 AM, Rowan Tommins <[email protected]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
