Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108028
MIME-Version: 1.0
References: <5e0d723f.1c69fb81.e2ae8.24e2SMTPIN_ADDED_MISSING@mx.google.com>
 <74F2DBFC-E63C-428C-A37F-2D0CEE15AD0F@newclarity.net> <DM5PR07MB30676FC66DA036895D5E3554F9200@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CD014984-715D-49C5-9A90-66C0A11F9818@newclarity.net> <c40a96fe-8929-4b44-98bd-3370a12ec516@www.fastmail.com>
 <D56361F6-8B11-4363-908D-962F683936BF@newclarity.net> <b32edf0c-451d-2281-8036-0b631a3c7a6f@gmail.com>
 <CD3AFCD7-EF2F-46C7-90D3-3A83A1D8836C@newclarity.net> <53556dfb-44ce-f902-204c-9a7da9484a61@gmail.com>
 <65567C7C-CF0F-4562-8943-F1F302134B07@newclarity.net> <f9e2f739-4964-b259-d9e5-4aeec938c54b@gmail.com>
 <F48FF1DC-5DE9-4C30-8BCF-C17A1877AF37@newclarity.net> <6f20bda1-eff6-631d-915f-d6bb149ee666@gmail.com>
 <93BA4B49-9D9A-4A41-83B3-8EC2564A70BF@newclarity.net> <CALKiJKoi7AH0ypkQN8p7S8jeO2M1qNnyMUfdDM+w4iLwhskskg@mail.gmail.com>
 <A819AFCE-875E-432E-9D87-EC4D970DF1DD@newclarity.net>
In-Reply-To: <A819AFCE-875E-432E-9D87-EC4D970DF1DD@newclarity.net>
Date: Wed, 8 Jan 2020 10:48:47 +0000
Message-ID: <CALKiJKqjXBr4jB7oh0gVPc9Q8ABgZaQ-=MzJb8Ry544Orr9oBA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c9b633059b9ea3af"
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000c9b633059b9ea3af
Content-Type: text/plain; charset="UTF-8"

On Tue, 7 Jan 2020 at 22:19, Mike Schinkel <mike@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]

--000000000000c9b633059b9ea3af--