Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107993
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <28c08b74-6c5a-429f-bd3d-1dbea2faebf2@www.fastmail.com>
Date: Sun, 5 Jan 2020 13:34:58 -0500
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <85A0C532-9126-48C6-9F59-1FB6B571D268@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>
 <70cbf5ab-2445-4003-987e-cb26301d64de@www.fastmail.com>
 <7A150D33-2434-401B-B687-E74B6E0F0AF8@newclarity.net>
 <21FF0232-D305-4E8F-9117-41D007E339D0@newclarity.net>
 <28c08b74-6c5a-429f-bd3d-1dbea2faebf2@www.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: mike@newclarity.net (Mike Schinkel)

> On Jan 5, 2020, at 12:02 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> I am saying that the behavior of a constant is that it is... constant. =
 A proper constant is evaluated at compile time and appears as a literal =
in the final runtime code, with no dereferencing.  AIUI, `const` in PHP =
does exactly that, in contrast to `define`.  That is fundamentally =
conceptually incompatible with a value that is derived at runtime and =
happens to use constant-style syntax. =20

Here is the problem with the crux of your argument. You are stating as a =
postulate that which you have not proven. The only reason constants are =
defined at compile time is that they have always been defined at compile =
time.=20

There is _no_ reason =E2=80=94 unless you can elaborate a specific =
tangible reason =E2=80=94 why a constant _must_ be defined at compile =
time vs. first access.  Doing the later does not change its essential =
state, i.e. it will still be "constant" and not change.

You are arguing from the perspective of a status-quo basis that =
constants are compile because they thus far have been compile-time. But =
preexisting implementation is not a valid argument for why something =
must continue to be the way it is.  Give me a conceptually valid reason =
why constants can only be defined a compile time and I may come to agree =
with you.  Otherwise I assert your arguments are just biased on current =
implementation.

> For derive-once global constants, you may be looking for `define`.  =
That's a runtime operation and effectively boils down to a set-once =
global.  It doesn't help with constants defined in a class, but for an =
already-global constant `define` already gives you a one-time set =
operation, just not on-demand. =20


Let's consider the fact that is PHP had never had the define() and =
instead implemented the `const` keyword from the start, and only allowed =
compile time values. If PHP had done that, you would be arguing from a =
status quo bias the same thing about making that dynamic. And it =
currently is dynamic which IMO invalidates your argument that constants =
must be defined at compile time.

> I am firmly opposed in principle to having a language construct that =
looks like a constant and makes you think it's a constant but is =
actually a method call that does who knows what.

Can explore why you are opposed to is, and see if we can find a way to =
address the use-case I proposed in another way?

> 1) I want an approximately global value that is auto-memoized on first =
usage, so I can access it from anywhere without having to recompute it =
or do the work of memoizing it myself.

I would rewrite this to say "I want a convenient syntax for values that =
tend to get hardcoded by developers that is easy to use and easy to read =
that is initialized on first usage so that it behaves like a constant."

> (I wouldn't want to limit it to global-ish things, either, because =
global-ish things are, as stated, bad in every way and should be avoided =
whenever possible.  Yes, I know there's a lot of bad code out there =
already with it; that doesn't mean encouraging it.)

I am going to argue that glob-ish things are _not necessarily_ bad in =
every way. They are bad when they introduce coupling and when they are =
mutable.=20

Global-ish is much less bad when immutable, and when structured to make =
tracking down usage easy.

But before you or anyone attacks me for saying this, realize that PHP is =
filled with globals that you happily use every day.  Class names are =
globals. Namespaces are globals. Functions are globals. And AFAICT =
immutable class constants are no worse globals than class names.=20

You can easily find where class constants are defined, and with a PHP =
analysis tool you can easily find every place where they are used, =
except for when people are using reflection or dynamic dispatch but they =
can do the same with classes and namespaces, so that's not an argument =
against class constants.

> For point 2... if you want to change your API, then your API is going =
to change.  That's what it means to change an API.=20

No, I said that I wanted the API to _not_ change. You are the one =
forcing the change constraint here. I am arguing code should be =
evolvable so that APIs do not need to change.

The more a language forces an API to change when requirements change, =
the more brittle and less fit-for-purpose the language is. The more a =
language does not allow refactoring without breaking an API the more it =
is a bad language, and that is much worse than some global constants =
IMO.

> Making code easier to refactor is all well and good, but not if it =
violates all expectations around what a constant is.

Let's explore the second part of this.

Languages change. And some times that changes expectations. To set the =
constraint that expectations cannot change is to force a language to be =
unable to improve.

Some examples of expectation change:

- PHP 7.4 preloading - My expectation is that the class files will be =
loaded on every page load, but with preloading they are not. =20
- PHP 7.4 custom object serialization - My expectation is that the class =
instance will serialize as the class was defined, but this changes that.

- PHP 7.3 const case-insensitive deprecation - My expectation that is =
constants are case insensitive, but now my expectation is no longer =
valid.
- PHP 7.3 const string search functions with integer needle - My =
expectation that is I can pass an integer, but now my expectation is no =
longer valid.

I could go on, but I think the point is the change in expectation is not =
an unreasonable thing to occur when a language evolves. We all have to =
continue learning.

> That's probably the better avenue to pursue for option 2, though again =
it's not one that I find worth compromising the language design for.

It many be changing PHP in a way you object to. But it does not =
"compromise the language design." That phrasing is a bit inflammatory.=20=


-Mike