Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107989
User-Agent: Cyrus-JMAP/3.1.7-694-gd5bab98-fmstable-20191218v1
Mime-Version: 1.0
Message-ID: <28c08b74-6c5a-429f-bd3d-1dbea2faebf2@www.fastmail.com>
In-Reply-To: <21FF0232-D305-4E8F-9117-41D007E339D0@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>
Date: Sun, 05 Jan 2020 11:02:22 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jan 4, 2020, at 3:25 PM, Mike Schinkel wrote:
> > On Jan 3, 2020, at 2:52 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
> >=20
> > There's two broad reasons I think this is a bad idea.
> >=20
> > 1) Constants are one thing.  Function calls are another.  They serve=
 different purposes.  Trying to mutate them into one thing can only lead=
 to confusion and lack of understanding about what is actually going on.=

> >=20
> > 2) The approach you describe (of starting with constants everywhere =
and refactoring to method calls later)... I would never do and do not en=
dorse.  What you describe is basically "make globals nicer to work with"=
, whereas I am 100% firmly in the camp of "if I could remove globals fro=
m the language entirely I would".  Frankly, the use of constants for con=
figuration is an anti-pattern to begin with; they should be used only fo=
r things that are truly constant.  Honestly, I cannot recall the last ti=
me I used constants for anything other than giving some other compile-ti=
me value a nicer name.  (Eg, DEFAULT_THING_VALUE or giving nice names to=
 bit flags or something like that.)
> >=20
> > For configuration, my answer is frankly "put your configuration behi=
nd a nice configuration object from the very beginning and then you won'=
t have to refactor it later; Problem solved."  You can use env vars for =
configuration, and wrap those into a nice object, possibly using one of =
the many DotEnv implementations that already exist to make them nicer to=
 work with in development.  That is superior in basically every conceiva=
ble way to semi-mutable globals passing themselves off as pseudo-constan=
ts.
> >=20
> > I *would* love to see property accessors come back, which would have=
 a side effect of making what you describe a little easier, but at no po=
int is it pretending to be a compile time value when it isn't.
> >=20
> > --Larry Garfield
>=20
> <sigh>  So much to unpack here, but I will just hit the most important=
 points.

*snip*

> Symfony =E2=80=94 which many PHP developers hold in high regard includ=
ing=20
> Drupal developers =E2=80=94 uses constants:

Just an FYI: I assume you mention Drupal specifically here because of my=
 history with the project.  What Drupal developers hold in high regard m=
atters not even 0% for me at this point; "Drupal does it" is not an argu=
ment that will carry any weight with me.

*snip*

> I think this analysis proves many PHP developers do use constants in=20=

> ways you claim you would never.  IOW, the use-cases I am trying to=20
> address exist to a significant degree in the wild.
>=20
> Further I believe I have made the case that there would be significant=
=20
> value in allowing developers who previously used constants because of=20=

> prior lack of skill or too-tight timelines to be able to evolve their=20=

> code to initialize their  constants with code instead of forcing their=
=20
> users to change their code or worse.
>=20
> -Mike

I think you are overstating my case.  I am not arguing that one should n=
ever use constants.  In fact, a majority of the examples you cite I woul=
d say are reasonable uses of constants, at least in concept.  (I cannot =
speak to the particulars of the individual code bases.)

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 conce=
ptually incompatible with a value that is derived at runtime and happens=
 to use constant-style syntax.  I am firmly opposed in principle to havi=
ng a language construct that looks like a constant and makes you think i=
t's a constant but is actually a method call that does who knows what.

There's really two different use cases here, I think, that we're conflat=
ing.  ("We" meaning I think we're all doing it to an extent.)

1) I want an approximately global value that is auto-memoized on first u=
sage, so I can access it from anywhere without having to recompute it or=
 do the work of memoizing it myself.

2) I have a code base with lots of constants, and I've changed my mind a=
bout the API (for whatever reason) and want them to no longer be constan=
t but runtime defined.

For point 1, I'd love it if we had some way to auto-memoize a result.  T=
hat would be sweet.  There's a couple of ways we could go about it... bu=
t I firmly believe that sticking it behind a const-like API is the wrong=
 way to do it for the reasons above.  (I wouldn't want to limit it to gl=
obal-ish things, either, because global-ish things are, as stated, bad i=
n 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 encoura=
ging it.)

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.  It's no different than=
 deciding to rename a method or class.  It may or may not be hard depend=
ing on the API and the install base, but that it's a constant doesn't ch=
ange matters.  Making code easier to refactor is all well and good, but =
not if it violates all expectations around what a constant is.

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-g=
lobal constant `define` already gives you a one-time set operation, just=
 not on-demand.  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.

--Larry Garfield