Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108043
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> <CALKiJKqjXBr4jB7oh0gVPc9Q8ABgZaQ-=MzJb8Ry544Orr9oBA@mail.gmail.com>
 <CBAAE45D-E957-4033-B93C-5D7995C7209E@newclarity.net>
In-Reply-To: <CBAAE45D-E957-4033-B93C-5D7995C7209E@newclarity.net>
Date: Thu, 9 Jan 2020 09:38:23 +0000
Message-ID: <CALKiJKqv_Q7vmPaOgzSzytZ5uH8jL7oFbbiLTNXpHTrh-mc-Bg@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e3788f059bb1c520"
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000e3788f059bb1c520
Content-Type: text/plain; charset="UTF-8"

On Wed, 8 Jan 2020 at 20:28, Mike Schinkel <mike@newclarity.net> wrote:

> > On Jan 8, 2020, at 5:48 AM, Rowan Tommins <rowan.collins@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]

--000000000000e3788f059bb1c520--