Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116521
MIME-Version: 1.0
References: <CALp5e-8xoj-RTcvmvDZ68c0pgAJBUcKhkLwZxNLspYhY6G6qEw@mail.gmail.com>
 <CAGBsUrcVjNmOJk8DnOmWzfmr5vVgjWbDzj-bYv1QGDXSdJz=Cw@mail.gmail.com>
In-Reply-To: <CAGBsUrcVjNmOJk8DnOmWzfmr5vVgjWbDzj-bYv1QGDXSdJz=Cw@mail.gmail.com>
Reply-To: Brady Wetherington <bwetherington@grokability.com>
Date: Thu, 25 Nov 2021 16:55:30 -0800
Message-ID: <CALp5e-8=sbQo1rCNW_Hf0Tw6v4PtPss7L9GoHq6XTev8Wh97=g@mail.gmail.com>
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [VOTE] Deprecate dynamic properties
From: internals@lists.php.net ("Brady Wetherington via internals")

> This is a little bit overly dramatic. This isn't such a huge change that =
would affect 50% of existing projects. It's likely to affect a small number=
 of projects in a very limited way.
> It's also not true that developers will slap #[AllowDynamicProperties] on=
 every class. That would imply that every class in their project is using d=
ynamic properties. That would be absurd. If it's truly the case that every =
class in 50% of the projects uses dynamic properties then we should not con=
sider this RFC at all. The whole premise of it is that it's highly unlikely=
 that many people are using dynamic properties on purpose. It's true that m=
any old unmaintained projects might use it as a feature, but the keyword is=
 "unmaintained". I would not trust dependencies that haven't been kept up t=
o date for a few years.
>
> I doubt that having to add a single attribute to a selected few classes w=
ould be such a major issue that projects would decide to stay on PHP 8.1 ra=
ther than upgrade. It's not comparable to Python 2/3 situation IMHO.
>
> I would be interested to know some numbers from Snipe-IT. Have you done a=
 preliminary analysis of your codebase of how many classes are actually usi=
ng dynamic properties? From a brief look, I can see that usually most prope=
rties are declared.

Sorry, I didn't mean to sound dramatic, just trying to share my concerns.

I suspect that you're very right, and *very very few* projects use
dynamic properties on purpose (in our own code, we probably don't ever
_mean_ to, except maybe for our Custom Fields feature, but we could do
the attribute for that one or so class(es)), but that's not my point.
I suspect many of our _dependencies_ might be using it (by accident,
to your point!). But I can't control every package in my
composer.json, which is where I'm worried. I can't force those
developers to do what I want, and I don't want to be stuck in a
'version sandwich' because I'm waiting for one of them to change
something. And maybe when they *do* try and change something, they
might also change the interface (a violation of semver, but, it
happens in the wild, more often than we would like). We have to
support old and new versions of php and that can make our Composer
situation a real nightmare (I just dragged us forward to be able to
work in PHPv8, and it was far harder than it needed to be).

I'm not worried about our code at **all** - we write it! We can change
it (and we'd be good citizens, I promise, we would!) And that
attribute is ignored on versions of PHP that don't support it; which'd
be fine for us. That's a fair ask, and we'd do it.

What I'm scared about is about our 42 dependencies in composer.json,
and the ~400k bytes of dependencies described by our composer.lock.

And I'm worried about other projects that have even more dependencies,
or might be stuck on a framework or something that's no longer being
updated, but they can't migrate off of for whatever reason. I wouldn't
wish that on anyone.

Thank you for considering, and for your extremely well-written response,

-B.