Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108027
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <CALKiJKoi7AH0ypkQN8p7S8jeO2M1qNnyMUfdDM+w4iLwhskskg@mail.gmail.com>
Date: Tue, 7 Jan 2020 17:19:03 -0500
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A819AFCE-875E-432E-9D87-EC4D970DF1DD@newclarity.net>
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>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: mike@newclarity.net (Mike Schinkel)

> On Jan 7, 2020, at 5:15 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> It seems to me that there are two different concerns there:
> <snip>
> So at its simplest, I would write something like this:
>=20
> class Environments {
>   const PRODUCTION =3D 4;
>   const STAGING =3D 3;
>   const TESTING =3D 2;
>   const DEVELOPMENT =3D 1;
>=20
>   public static $branches =3D [
>        self::PRODUCTION =3D> 'master',
>        self:: STAGING =3D 'stage',
>        self:: TESTING =3D 'test',
>        self:: DEVELOPMENT =3D 'dev',
>    ];
> }

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.

That said, I would not want to implement as you propose. I prefer to =
have values that can change be declared at the top of the class as =
constants where they are _not_ obscured by extra syntax =E2=80=94 as in =
your example with brackets, self::, and fat arrows =E2=80=94 so as to =
make them the most scannable.

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.

> It's not a feature of constants, it's a feature of strings and arrays,
> because they are implemented as objects. The same trick would be =
possible
> in PHP if constants could have objects as values:

Even so, in Ruby you can define constants dynamically at runtime.

That said, maybe I should be requesting that PHP constants be able to =
have objects, too...?

> 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."=20

What should only matter is what makes more sense moving forward.

> If we take these two statements really literally, you can do =
everything you
> want already:

Except there was a third statement you did not reference:=20

- "My primary goal is to be able to modify constants in _existing_ code =
to be initialize at runtime to support evolvability/refactoring."

> 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.

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.

> 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?

> For the record, I think generators are a really neat feature, but
> absolutely hate that they are declared with the "function" keyword, =
and
> hate that they reuse the "return" keyword for "set final value".
>=20
> So, yes, that's a good example of something that breaks people's
> expectations of what keywords mean, and I think that's a bad thing.

I was not pointing out the naming, I was pointing out how confusing the =
features are to understand and use regardless of naming.

But I am not arguing that we do not including confusing features. To the =
contrary, I think we should include more power in the language, even in =
places it might be confusing.=20

Just not Ruby-level power a.k.a. ability to completely redefine the =
language level of power. :-D

> I'm not saying it's impossible to account for it, I'm just saying =
there may
> be a lot of tools out there which would need to be updated. Saying =
"simply"
> doesn't make it so!

That can be said about every language enhancement, so as an argument =
against a feature it feels a bit contrived.

> I was thinking much more abstractly: some code of some sort that runs =
as a
> separate build step, and produces some kind of output that can be
> referenced cheaply at run-time.
>=20
> In particular, I was imagining the pre-processor being fully aware of =
the
> language's syntax, and operating at the AST level. You could view it =
as an
> extension of compiler optimisations: explicitly saying "run this =
before you
> even deploy to the server, the result will never change".
>=20
> The output to PHP is necessary for the same reason client-side =
languages
> are transpiled to JavaScript - it's the language spoken by the target
> run-time. If we could treat OpCodes as a stable target, like .NET CLI, =
or
> Java bytecode, it could target that instead, but it wouldn't actually =
make
> much difference to the operation of the pre-processor. There is of =
course a
> side-effect that the resulting PHP code can be read by a human, making =
it
> easier to debug.

After posting my objection to pre-processing I remembered there was =
another reason I object to pre-processors that is even more significant =
than lack of composibility.  And my objection extends to all the =
transpiring being done with Javascript and CSS too, although I put up =
with those because the community has mitigated some of the worst =
problems and because so many developers have embraced them.

The other objections I have to pre-processing:

1. It adds a build step to testing. PHP currently does not need a build =
step and so the code-run-test cycle is not interrupted by a build step.

2. Build steps are non-trivial to set up and keep running. The front-end =
developers I work with are always having some kind of problem with their =
build process.

3. The source is no longer the production code. This means line numbers =
and possibly other things in the error log no longer match the source =
code.

4. Debugging is much harder.  For PHP, XDEBUG does not understand =
preprocessed code.=20

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.

-Mike