Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108012
Message-ID: <54CAFCD7-2B99-4BA4-8A5F-3D7EBC9D810B@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1D076EB7-3A84-4D3E-9C0D-D6B7F211BC08"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 6 Jan 2020 15:28:56 -0500
In-Reply-To: <d18fd45b-814c-49dc-80de-4e71da95acb7@www.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <5e0d723f.1c69fb81.e2ae8.24e2SMTPIN_ADDED_MISSING@mx.google.com>
 <74F2DBFC-E63C-428C-A37F-2D0CEE15AD0F@newclarity.net>
 <DM5PR07MB306700E1BEEB2F7D25B445EBF93D0@DM5PR07MB3067.namprd07.prod.outlook.com>
 <CAMuFt-6PYPyZ8ri-19dP1tE1TWmcW0j0utfmDvZtmn3cGe24kA@mail.gmail.com>
 <d18fd45b-814c-49dc-80de-4e71da95acb7@www.fastmail.com>
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_1D076EB7-3A84-4D3E-9C0D-D6B7F211BC08
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jan 6, 2020, at 1:07 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> Do not put words in my mouth and presume to know what I would think in =
some hypothetical situation.  That is rude and inappropriate.

I do not mean to nor want to start any conflict here. I know I felt some =
of your phrasing rude and so I was probably writing in frustration. =
Hopefully we can both moderate as conflict is not good for any of us.

> You also repeatedly are accusing Rowan and I of "status quo bias" as =
though it were a bad thing.  Let me be clear: I entirely agree with Zeev =
that in a language used by millions of people a "status quo bias" is a =
*very good thing*. =20

You are misunderstanding the definition of "status quo bias."  Here is =
part of the definition: =20

"Status quo bias is an emotional bias. The current baseline (or status =
quo) is taken as a reference point, and any change from that baseline is =
perceived as a loss. Status quo bias should be distinguished from a =
rational preference for the status quo ante, as when the current state =
of affairs is objectively superior to the available alternatives, or =
when imperfect information is a significant problem." =20

When I used that phrase I was specifically referring to the emotional =
reaction vs. the rational reaction. I understand and agree when rational =
arguments are used, but lately in our political climate people seem to =
often to start with emotional arguments. And calling something an =
anti-pattern or the alternative a "best practice" is not a rational =
argument; both of those are loaded words.

From: https://en.wikipedia.org/wiki/Status_quo_bias

But if I mischaracterized your objections I apologize. =20

> So you call something an anti-pattern, then get on my case for "appeal =
to authority" for calling something an anti-pattern?  Your argument =
style needs work, dude.

I notice you did not quote my full statement. I explicitly called out =
the irony of my own usage and made the distinction that I was not using =
the phrase to argue against someone else's proposal which is why I felt =
ok to use it, because I was not using it to block anyone else's needs.=20=


Again, my goal is not conflict but hopefully improving PHP.

> Global data is well-recognized across the industry as dangerous, and =
the larger the system the more dangerous it is.

Eh, not exactly.  Global data that is *mutable* is bad.  Immutable =
global data =E2=80=94 especially constants =E2=80=94 are not necessarily =
bad, at least per the highest voted answer which means the topic is =
definitely debatable:

https://stackoverflow.com/a/1265684/102699

And a constant that is initialized at runtime is still immutable through =
the life of the execution.

>  It violates pure functions, and pure functions are how you get any =
semblance of predictability in your code. I do not have the time or =
inclination to go through all the details of that here; you can find =
ample resources for that yourself.

I am very familiar with pure functions, you don't need to go through the =
detail with me.

That said, class methods in PHP are not pure functions and PHP has not =
embraced pure functions so I am not sure why you are using this your =
rational other than maybe you wish PHP was a pure-function language?   =
Of course if it was limited to pure functions, we'd not be able to =
configuration from outside the program anyway.

> (And for the record, "appeal to authority" is only a logical fallacy =
if the authority being appealed to is not a qualified authority on the =
topic at hand.  Appealing to Tiger Woods's authority on golf clubs is =
not a logical fallacy because he really would have more knowledge and =
experience than most; appealing to his authority on baseball gloves =
would be a logical fallacy.)

When you said it was an anti-pattern you used passive voice and did not =
include a reference to any authority.

That said, I have been programming professionally for 30 years now and I =
have seen many best practices from "authorities" be promoted, and then =
later seen a tidal wave of developer sentiment argue against those same =
best practices, i.e. inheritance and then containment, as one example.

I've also seen authorities promote an idea and then watched as =
developers latched onto it and give it a life of its own, far outpacing =
what the authority orginally intended, e.g. Bob Martin and the single =
responsibility principle.

In my experience "best practice" and "anti-patterns" are too often used =
in debate even when they do not actually apply to the use-case, so I =
prefer to dispense with those words when trying to debate actual pros =
and cons of an approach.

> I work for Platform.sh, which has been doing =
environment-per-bit-branch longer than Pantheon has. =20

That statement was in response to Rowan's comment, not yours.

> In my experience, systems that configure themselves via constants are =
the worst. =20

Of course they are the worst! Because you can't initialize constants =
dynamically.=20

That is exactly what I am trying to change.

> It makes any sort of dynamic override (which you *must* do in a cloud =
hosting environment) a PITA. =20

Exactly.

> The best option are systems that are configured by env vars, and have =
a very clearly set of documented env vars to populate.  Env vars are =
also globally readable but you're not tricked into thinking they're =
compiled out at compilation time (as things with `const` are.)  They're =
also by far the easiest for me to work with as the person writing that =
glue code.

The word "tricked" is a pejorative and not helpful for our discussion. =20=


What I read here is that you have a preference for using Env vars =
directly and I have a preference for encapsulating them into constants.  =
I don't see that either of us are more "right" than the other, we just =
have different preferences.

I still have not heard a real reason why Api::URL is somehow worse to =
use than $config->api_url() other than your claim that the former is =
"global" and thus bad, which I challenge because the former would be =
immutable.  This is one of the areas where I think the "anti-pattern" =
does not apply.=20


> Adding language features that make it easier for people to take the =
approach that is in my experience the most painful option is something I =
am not going to support. :-)

Have you worked with other languages besides PHP where dynamically =
initialized constants were possible, and this caused problems?

> To the use cases, "I'm changing the API but don't want to change the =
API" (what you're calling evolving here)

As you said above that it was rude to put words in your mouth, it is =
also rude to keep changing my words to better fit your argument. Let us =
both not do that.

>  "Sometimes a constant is not a constant". =20

What I proposed will always be a constant.  Again, it would be immutable =
once set.  The fact is it set at compile time does not make it constant, =
per the lin

> =46rom one perspective one could look at dynamically valued constants =
as a zero parameter self-memoizing function with some syntactic sugar.

Yes.

Although I tend to avoid using the term "memoizing" because most people =
I know have to look it up and then ponder over its meaning.

> I can see a use for const variables, especially const class variables. =
=20

I assume you mean immutable variables that still use the $, like 'let' =
in Javascript?  =20

Those would definitely be very useful, but unfortunately would not =
address the use-case I presented.

> So the more general request here is for dynamically valued constants =
beyond the current `declare` support.  Which... I could potentially get =
behind.  Self-memoizing functions is one way they could be implemented, =
if you don't mind ().  (I don't.)  That would also have a lot of other =
benefits.

I am confused. This sounds like you are now agreeing with the need for =
dynamic constants?

BTW, the requirement for () means it would not address the use-case of =
allow code to be evolved.

> The caveat in both cases is dependencies.  Memoizing an impure =
function can lead to all sorts of time-dependent silliness.  The same =
concern applies to dynamically valued constants.  If their generation =
code is a pure function (however expressed), then cool, that's a safe =
and nice feature.  If it has unpredictable dependencies, though, the =
behavior can be equally unpredicatable.  That includes depending on =
$_GET or env vars.=20

Totally agree that people could write bad code. But there are a thousand =
ways they can already write bad code. =20

If a dynamic constant were to use $_GET or $_ENV it could be =
problematic, but it could also be coding in a manner than it would be =
completely robust, and making it robust is not hard.

>  (Remember, PHP has plenty of users outside of shred-nothing requests, =
and with FFI and preloading hopefully more of them wil get used more =
often.)

Maybe there is something here I am missing? Can you present a problem =
that dynamic initialization of a constant would create only a statically =
defined constant in these cases.  I cannot think of one, but I will be =
honest and admit that does not mean there is not one.

> So I could get behind dynamically valued constants and/or =
auto-memoizing functions.  That would probably mean they still have a $ =
on them, which doesn't bother me.  That clearly separates them visually =
from macro constants, which I like.

Having the $ requirement blocks my primary use-case, so it would bother =
me.

> The potential for hard to find bugs here is high; although the counter =
point is that using a function/method to emulate them today, which you =
can absolutely do, offers the exact same risk. =20

And that's the key point. It really is no different from what we have =
today, except that what I proposed would provide evolvability.

> The trick is when exactly these run, because they're impure functions =
so whether they run at code compile time or first-access could mean a =
dramatic difference in their resulting value.  And that is precisely why =
I am very, very nervous about allowing impure functions to be cached, =
whatever the syntax on top of them.  (Constant-like or not.)

When you say "cached," what are you thinking the lifetime would be?  And =
how would that really be different from a static constant? =20

Are you concerned that the code could fail and leave the constant in an =
invalid state? =20

A potential way to address that is for a dynamic constant to require =
type hinting, and thus if it did not return the correct type it would =
fail with an easy to trace error output. And also disallow throwing =
errors outside of the constant. That would force developers to write =
robust dynamic constant code.

-Mike=

--Apple-Mail=_1D076EB7-3A84-4D3E-9C0D-D6B7F211BC08--