Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116519
MIME-Version: 1.0
Reply-To: Brady Wetherington <bwetherington@grokability.com>
Date: Thu, 25 Nov 2021 15:16:38 -0800
Message-ID: <CALp5e-8xoj-RTcvmvDZ68c0pgAJBUcKhkLwZxNLspYhY6G6qEw@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [VOTE] Deprecate dynamic properties
From: internals@lists.php.net ("Brady Wetherington via internals")

Sorry for the 11th hour chime-in, but I wanted to add some context
about this proposed change, and how it would likely affect our project
and many others. I know the prospect of opt-in was already addressed,
but I wanted to talk about what our experience would be here. (We make
Snipe-IT, which is open-source but also a paid-for-hosting or
pay-for-support project).

Many modern PHP projects (like ours) have 10's or 100's of
dependencies, often installed via Composer. With this change, many of
those will start to throw deprecation warnings - eventually failing in
PHP v9. Not every package is equally modern, or equally
well-maintained. I suspect there are plenty of newer packages that
will "Just Work=E2=84=A2" and that's great! But there are probably many old=
er
packages, or more poorly-maintained ones, that will not.

Packagist has around 3 million packages. Figure half are "not modern"
(needing updates to be compatible with the proposed change) - that'd
be 1.5 million packages. (And that's probably pretty conservative).
Figure it takes an hour, each, to fix them all (again, that's
conservative). That's 1.5 million hours, which is 171 developer-years.
That's effectively 2 or 3 developer lifetimes (probably more, if we
try to include work-life balance and whatnot :P )

And what are 9 out of 10 maintainers going to do? They'll just plaster
#[AllowDynamicProperties] in front of every class, and be done with
it. Voila! Compatibility. So the bulk of those 171 developer-years
will be wasted.

I think opt-in would be a better approach - per-class, certainly
(#[FixedProperties] or #[StaticProperties] maybe?), but maybe per-file
as well, or maybe even in php.ini if we want to go per-project.

Different language front-ends to the php back-end engine could
certainly by default jam the attribute in on every class; that'd be
fine. But for PHP itself, one of its massive selling points has been
that it tries very hard not to break compatibility - I have written
code for PHP v4 that I have been able to drag up to PHP v7.x without
too much work. I'd hate to lose that, or make it much harder -
especially for dependencies that I don't have direct control over.

By no means am I suggesting that PHP is a 'dead language' - but let's
not cram ourselves into a Python2/Python3 compatibility hole where we
make upgrades into a nightmare for people. Adding types for variables
and parameters has been optional and is gradually becoming the
standard thing to do; I'm sure this would end up the same.

Anyways, hoping to just add some more context for those who are voting
on the proposal. Feel free to ask any questions you'd like and I'll be
happy to answer as best I can.