Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116406
MIME-Version: 1.0
References: <6192EEDA.8050900@adviesenzo.nl> <CADK1yXKp7OXYa0GjxG-B+Jk=GxGET7dtwUb4efFVFNfQXuiADg@mail.gmail.com>
In-Reply-To: <CADK1yXKp7OXYa0GjxG-B+Jk=GxGET7dtwUb4efFVFNfQXuiADg@mail.gmail.com>
Date: Tue, 16 Nov 2021 10:22:54 +0000
Message-ID: <CAJvSBVO6nSqD7PLCRLARaf0O3fciE5+myNgctjtS6vcBuEa=Mg@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: php-internals_nospam@adviesenzo.nl, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000012274305d0e551a2"
Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
From: phpmailinglists@gmail.com (Peter Bowyer)

--00000000000012274305d0e551a2
Content-Type: text/plain; charset="UTF-8"

Hi list,

On Tue, 16 Nov 2021, 00:21 Deleu, <deleugyn@gmail.com> wrote:

> I see a pattern in these discussions from two mindsets: one thinking about
> how we should design the future and another thinking about how we preserve
> the past.


I would frame that differently as those who
1. Predominantly write new code (most of us on this list I expect)
2. Use ecosystems written in PHP (talking from personal experience I have
WordPress and Drupal in mind, but I see it with Laravel and to a smaller
extent Symfony users too).

Both approaches are massive audiences for PHP and both have different
needs.

For the second group, finding that something you built on no longer works
because "PHP changed" is a problem, in a way it isn't for members of this
list, who would likely fork and fix it. It's easy to use the glib response
that "it's open source, they should get their hands dirty" but for many,
knowing how to get started is a barrier that stops them. Making a big
generalisation, this audience is hugely proud of what they do manage to
accomplish and can be hugely vocal proponents for PHP (ecosystems).

Yet it's not always lack of knowledge either that makes small
backwards-incompatible changes a problem. If you're a small business your
focus is elsewhere and what those working at larger and highly profitable
or well funded companies see as a small expense (however annoying) is a big
loss of other opportunities that a small business could use to grow. I see
this with some clients, where a day is a big deal, and a day spent testing
an upgrade is a day not spent fixing the problem 5% of customers have.

I take it as read that we want to continue serving both audiences.

On improving PHP, there is a prevalent view on this list that the
competition is people going to other programming languages. The hidden
competition is people saying "keeping up isn't worth the effort" and
switching to centralised SaaS offerings. We see all the good reasons for
doing this playing out in our own "Switch to GitHub Issues" discussion.
It's happening enough, we don't need to encourage it.

Returning to this RFC it may surprise people that I like the idea of only
having dynamic properties on stdClass & children. I don't go as far as
saying "this is how it should have been from the start" as the culture was
different when classes were introduced to PHP. But dynamic properties have
been around since the start and I am wary of deciding to remove them in PHP
9.

Kind regards,
Peter

--00000000000012274305d0e551a2--