Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107987
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <b32edf0c-451d-2281-8036-0b631a3c7a6f@gmail.com>
Date: Sat, 4 Jan 2020 17:40:58 -0500
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <CD3AFCD7-EF2F-46C7-90D3-3A83A1D8836C@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>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] Initializing constants once, with code?
From: mike@newclarity.net (Mike Schinkel)

> On Jan 4, 2020, at 10:49 AM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> This is, as so often with such comparisons, an exaggeration: the =
docblock for a function need not be any longer than the docblock for a =
constant, and the function body can be simplified.

Fair point. =20

> Add in the "initialise on first read", and you end up with 4 lines per =
pseudo-constant vs 5 per method:

But then you give an example which exaggerates in the other direction. =20=


The point was when constants ARE used they result in a lot more compact =
and infinitely more scannable code. Thus when you do not actually need =
to use initialization code you do not have to and you get much more =
scannable code, but you have the _option_ to add initialization code =
_later_:

class Environments {
   const PRODUCTION =3D 'master';
   const STAGING =3D 'stage';
   const TESTING =3D 'test';
   const DEVELOPMENT =3D 'dev';
}

vs.=20

class Environments {
   static function PRODUCTION() {
      return 'master';
   }
   static function STAGING() {
      return 'stage';
   }
   static function TESTING() {
      return 'test';
   }
   static function DEVELOPMENT() {
      return 'dev';
   }
}

What I am asking for is the ability to _evolve_ code over time and not =
force code to forever retain its technical debt simply because of =
initial choices.=20

And not just for constants, but for evolvability of all code. To me that =
seems like such a no-brainer best practice for programming language =
design that I am struggling to understand the fundamental objections to =
it.

> Overall, I agree with Larry that these aren't really constants, and =
shouldn't be treated as such.

The fact constants are limited to literal code is merely a limitation of =
the opcode compiler, not a conceptual difference.  In both cases they =
are initialized before use, and then never changed. If they are =
immutable once initialized, then they are conceptually constants.=20

And if the opcode compiler could offer more expansive initialization =
than just literals then my use-cases would likely be addressed.

Another approach would be for me to ask for an `immutable` option that =
has the behavior I am proposing, but that would not empower the millions =
of constants in the wild that already exist to evolve and would only =
benefit new code:

class Environments {
   immutable PRODUCTION =3D 'master';
   immutable STAGING =3D 'stage';
   immutable TESTING =3D 'test';
   immutable DEVELOPMENT =3D 'dev';
}

Yet another approach would be for me to ask for would be for a shortened =
function declaration syntax. But again that would also not empower =
existing constants to evolve:

class Environments {
   function PRODUCTION =3D 'master';
   function STAGING =3D 'stage';
   function TESTING =3D 'test';
   function DEVELOPMENT =3D 'dev';
}

> Property accessors, or some native support for lazy-loading properties =
(which would stop Doctrine needing to do tricks with unset() and __get), =
would seem like a better fit for the use case.

I would also LOVE property accessors added to PHP, but I disagree it =
would address the use-case of existing constants in libraries in the =
wild (and in future code) that are forever cursed to remain as hardcoded =
literals to ensure backward compatibility.

Both you and Larry have redefined my use-case to an idealogically =
convenient use-case.  Can we please address the use-case as I am =
defining it: existing code that already uses constants and future code =
where developers use constants because of lack of skill, awareness of =
"best practices", or too-tight timelines? =20

Maybe there are other solutions for the use-case I am trying to address =
besides the one I proposed, but we can't get there if everyone redefines =
the use-case to support their arguments.

-Mike=