> On Jan 4, 2020, at 10:49 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
>
> 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.
> 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.
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 = 'master';
const STAGING = 'stage';
const TESTING = 'test';
const DEVELOPMENT = 'dev';
}
vs.
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.
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.
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 = 'master';
immutable STAGING = 'stage';
immutable TESTING = 'test';
immutable DEVELOPMENT = '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 = 'master';
function STAGING = 'stage';
function TESTING = 'test';
function DEVELOPMENT = '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?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
