On Tue, 7 Jan 2020 at 22:19, Mike Schinkel <m...@newclarity.net> wrote:
> 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. > Yes, I dived quite deep into that one example, mostly because I was trying to understand why you picked it. I do think it's important though to demonstrate that a new language feature meets a real and common need, rather than just an interesting theoretical possibility. 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. > That would be the case if the language didn't support either, and we were choosing between, but we're not. I'm arguing for using the existing features of the language to solve the problem, whereas you're saying we need to add a new way to do it. That requires a higher bar than "it's not objectively worse and I happen to like it". > That said, maybe I should be requesting that PHP constants be able to have > objects, too...? > If they can be initialised at run-time based on arbitrary code, it's going to be hard to avoid including that in the implementation, because at the moment constants are restricted not by types of value, but types of expression, so I'm not sure you could say at runtime "does this value look constant-y?". > > 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." > You've lost the context here. You said "Python did not feel there was a need"; I was saying maybe they thought there was a need, but hadn't found a solution. It's all beside the point anyway: PHP already has compile-time constants, so without a time machine, our discussion has to start from that basis. > > 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. > Your last e-mail seemed to say completely the opposite; maybe I misunderstood: > As for immutable variables, I see those as very useful to, but I think their use-cases are orthogonal to the use-case I was trying to address. 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. > 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. > I asked for examples because it's useful to examine them and see how they're similar and how they're different. The "technicality" is that Java didn't introduce a syntax for compile-time constants and extend it with initialisation, they introduced a restriction which can be applied to any variable, and which when used in a certain way is roughly equivalent to a compile-time constant. 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. > > 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? > A couple of things come to mind: - tools that examine expressions involving constants for things like unreachable code, wrong types used, etc, would need to treat run-time-initialised constants specially - constants could now presumably be any type, including mutable objects, which is likely to break a bunch of assumptions > 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. > At the point where you have different pieces of code run at "pre-load" and "execution", that to me is equivalent to having a pre-processor that outputs OpCodes rather than PHP code (and thus is possibly easier to do things like present correct line numbers to debug tools). Running the pre-processor on preload sounds tempting, but we'd need some way to get input from the environment to the preloading routine, and would need to initialise enough of the VM's runtime state to allow code to be executed rather than just compiled. There'd also be cases like command-line unit tests where users would still need to mess around getting the environment right, just like with a traditional build step. It mostly boils down to "run build step automatically on server start", rather than actually eliminating the complexities of the build step itself. Regards, -- Rowan Tommins [IMSoP]
