Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Levi Morrison via internals]

> if hosting it ourself is a priority, i suggest looking into GitLab’s
> Community Edition, which is entirely open source,
> and the GNOME project moved from Bugzilla to GitLab CE in 2018,
> here's how that worked out, 2 years later:
> https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/
> (and the TL;DR is that it worked out great for the GNOME project)

In my opinion, _not hosting it ourselves_ is a priority. Part of what
bugs.php.net has shown is there is a lack of people who want and are
willing to do the systems and maintenance tasks to run our own
infrastructure. In this sense, I quite like GitHub, as it is one less
thing that we have to maintain. Sure, we will have some custom tags,
but this is quite minor compared to maintaining a system.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

Hi,

On Tue, Nov 16, 2021, 4:40 AM Matthew Brown 
wrote:

> On Fri, 12 Nov 2021 at 08:08, Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I've opened the vote on
> > https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> > 2021-11-26.
> >
> > Regards,
> > Nikita
> >
>
>
> I encourage people to vote "yes" on this, if you want PHP to be better
>

My vote will change to yes as soon as the change is an opt-in instead of an
opt-out for the 8.x lifetime.

best,
Pierre

>

[PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Mark Randall]

On 15/11/2021 23:35, php-internals_nos...@adviesenzo.nl wrote:
Either way, in my estimation, handling this deprecation will - again - 
require not insignificant dev-time from maintainers to determine the 
best course of action for each flagged instance and to implement the 
changes, and what with the stagnation in OSS already happening, I wonder 
if now is the right time for adding this to their work-load, especially 
with the relatively flimsy argumentation for this RFC.



Can you approximate how much time you expect this to take?

Adding #[AllowDynamicProperties] to the top of each class seems like it 
is unlikely to be something that would take much time, and will almost 
certainly be catered for by automated tooling such as Rector before too 
long. Even without such tools, it could be applied by hand to hundreds 
of files in under an hour. Do you have a reason this is not the case?


Of course, the downside to this is that by doing so it may cover up 
existing bugs that this change is meant to help identify.


A distinction must be drawn between changes that MUST be made to be 
compatible, and changes that SHOULD be made because your code is 
carrying tech debt.


I would be interested in hearing how much of the workload you are 
experiencing falls into each category.


...

To cover the other point which is more subjective:

The inability for certain open source projects to keep up should 
absolutely not be a reason for PHP to slow down its development.


While OSS library projects are certainly important to the ecosystem, 
they represent a tiny fraction of the code that is written, and are 
often constrained by a small number of contributors to work on them, 
often times only a single person.


Should millions of other developers be held back because of the weak 
foundations of certain OSS projects? I think to do so would be a 
collosal mistake.


Yes, that means that some of these projects will not be able to do 
what's necessary and will fall into disrepair and be abandoned. I 
personally consider that an acceptable loss when compared to all the 
benefits these changes bring.


We must look to the future, for every line of PHP code that has ever 
been written, it's likely that there will be hundreds if not thousands 
of additional lines that will be written in the future, many of which 
will by people who have never written a single line of code before, in 
any programming language.


For that reason it is essential that PHP's out-the-box experience is 
sane and safe(ish) by design, and that means that common-sense defensive 
coding mechanisms should be the default, not something that you have to 
opt into, even if that means that old code will need to be modified to 
be compatible with those measures.


To do otherwise would be entirely unethical.

--
Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Deleu]

On Tue, Nov 16, 2021, 00:36  wrote:

> L.S.,
>
> As some of you may have seen, I posted a thread on Twitter a few days
> back referencing this RFC:
> https://twitter.com/jrf_nl/status/1459221549429542920
>
> I've been asked to post the link to the Twitter discussion in this
> thread for visibility.
>
> The Twitter thread generated, and is still generating, quite a lot of
> discussion, which I believe is a good thing and I'd like to thank
> everyone of you who has been actively participating in these discussions
> and has taken the time to read the various opinions.
>
> The thread, however, is not specifically about this RFC, but more about
> the more poignant issue of the current pace of deprecations in PHP, the
> impact of the workload these cause for open source project maintainers
> and the stagnation I'm currently seeing in PHP open source releases and
> innovation as a result of this.
>
> As I'm posting here now anyway, I'd like to leave the following feedback
> for your consideration:
>
>  From what I've gathered from responses and the added "Motivation"
> section (thanks Nikita), this RFC is intended as a stepping stone
> towards eventually removing support for dynamic properties from PHP
> completely.
> This only got cursory mention in the RFC and the RFC as it is, does not
> lay out a clear path towards that end-goal.
>

If memory serves me right, Nikita planned to always leave dynamic
properties bound to a single class (possibly stdClass as it is its natural
use). That would have allowed for performance improvement on the engine.
However, as we've seen from the Serializable RFC, planning out a 2-major
change means voting today for a change that will only take place in 10
years. That's too long of a time to predict whether the change being voted
even makes sense. As it currently stands, I believe the RFC outlines the
best it can do with the context in which we are. If nothing else ever
happens in the matter, we're left in a better place anyway.


> What I miss in this RFC - and also oftentimes in other RFCs over the
> past few years - are:
> * The real reason behind this change proposal. "Modern code doesn't use
> this" is not a reason and also not always true.
> * An impact and workload analysis for userland PHP code, no matter how
> tentative.
> * Argumentation that this is the right stepping stone towards eventually
> being able to achieve the end-goal of removing support altogether and a
> tentative outline of what the path towards that end-goal will look like,
> both in timeline, next steps and (tentative) criteria of when it would
> be acceptable to take those steps.
>

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. In the past static analyzes wasn't even a thing in PHP. Nowadays
we produce code that is much more likely to be analyzable in the future
than a decade or two ago. The camp of people that has to deal with code
that "is better left untouched" will often find these type of RFC lacking
in motivation i.e "why are you making me touch that code that I don't want
to touch or shouldn't have to touch?". Likewise the people that has already
suffered through these code and want to prevent them from being a constant
problem will need little convincing that the change is good.


> Without the above, the RFC as it currently is, is IMHO just creating
> more busy-work without a clear path forward.
>
> Please also take note that while this deprecation may not have much of
> an impact on applications which have full control over their server and
> the PHP version on which the code is run, as those have a) full access
> to server logs and b) can use tools like Rector to upgrade (once a
> Rector for this has been written), this is a whole different ball-game
> for open source.
>
> As pointed out before, static analysis tools (once written) can help,
> but may struggle to analyse the code using dynamic properties correctly
> in all cases.
>
> In the end, if this gets deprecated, the best way to find the potential
> problematic instances, is, like always, a test suite with near full code
> coverage to see all deprecations, but let's also be realistic: a full
> test suite is a luxury few open source projects actually have.
>
> And even when a full test suite is available, and this is probably the
> most important problem I see: **open source libraries are generally
> building-blocks in a larger whole, where the library itself has no
> control over how their users are using the code, let alone have any
> indication of whether their users may be using or extending the library
> in ways which _rely_ on dynamic properties.**
> This uncertainty may lead to "abuse" of the attribute to prevent
> introducing a breaking change.
>

I know you didn't mean it that way but I can't help but interpret this as a
great motivation on why this RFC should be approved. It allows for a world
to exist (in 3 years) 

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Matthew Brown]

On Mon, 15 Nov 2021 at 17:32, Chase Peeler  wrote:

>
>
> On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown 
> wrote:
>

>
>> I encourage people to vote "yes" on this, if you want PHP to be better at
>> preventing people from shooting themselves in the foot.
>
>
> What if I want a language where people can shoot themselves in the foot
> because the flexibility it offers is what makes it great
>

I don't think this particular feature makes PHP great, and I don't think
the active PHP community thinks that either.

I know there are
>> valid uses for this, but it's nevertheless a surprising feature, and not
>> one that delights many PHP developers.
>
>
> Why is this surprising? It's been available since classes were introduced
> to PHP.
>

Not everyone who uses PHP has been using it since time immemorial. Some of
us came from compiled languages where this behaviour is expressly
prohibited, while others are used to interpreted languages that  also
prohibit this behaviour.

This is what I mean by surprising: I have heard newcomers express literal
surprise when discovering this for the first time, and not in a delighted
way.

Best wishes,

Matt

[PHP-DEV] Re: [RFC] Deprecate dynamic properties

[php-internals_nospam]

L.S.,

As some of you may have seen, I posted a thread on Twitter a few days 
back referencing this RFC: 
https://twitter.com/jrf_nl/status/1459221549429542920


I've been asked to post the link to the Twitter discussion in this 
thread for visibility.


The Twitter thread generated, and is still generating, quite a lot of 
discussion, which I believe is a good thing and I'd like to thank 
everyone of you who has been actively participating in these discussions 
and has taken the time to read the various opinions.


The thread, however, is not specifically about this RFC, but more about 
the more poignant issue of the current pace of deprecations in PHP, the 
impact of the workload these cause for open source project maintainers 
and the stagnation I'm currently seeing in PHP open source releases and 
innovation as a result of this.


As I'm posting here now anyway, I'd like to leave the following feedback 
for your consideration:


From what I've gathered from responses and the added "Motivation" 
section (thanks Nikita), this RFC is intended as a stepping stone 
towards eventually removing support for dynamic properties from PHP 
completely.
This only got cursory mention in the RFC and the RFC as it is, does not 
lay out a clear path towards that end-goal.


What I miss in this RFC - and also oftentimes in other RFCs over the 
past few years - are:
* The real reason behind this change proposal. "Modern code doesn't use 
this" is not a reason and also not always true.
* An impact and workload analysis for userland PHP code, no matter how 
tentative.
* Argumentation that this is the right stepping stone towards eventually 
being able to achieve the end-goal of removing support altogether and a 
tentative outline of what the path towards that end-goal will look like, 
both in timeline, next steps and (tentative) criteria of when it would 
be acceptable to take those steps.


Without the above, the RFC as it currently is, is IMHO just creating 
more busy-work without a clear path forward.


Please also take note that while this deprecation may not have much of 
an impact on applications which have full control over their server and 
the PHP version on which the code is run, as those have a) full access 
to server logs and b) can use tools like Rector to upgrade (once a 
Rector for this has been written), this is a whole different ball-game 
for open source.


As pointed out before, static analysis tools (once written) can help, 
but may struggle to analyse the code using dynamic properties correctly 
in all cases.


In the end, if this gets deprecated, the best way to find the potential 
problematic instances, is, like always, a test suite with near full code 
coverage to see all deprecations, but let's also be realistic: a full 
test suite is a luxury few open source projects actually have.


And even when a full test suite is available, and this is probably the 
most important problem I see: **open source libraries are generally 
building-blocks in a larger whole, where the library itself has no 
control over how their users are using the code, let alone have any 
indication of whether their users may be using or extending the library 
in ways which _rely_ on dynamic properties.**
This uncertainty may lead to "abuse" of the attribute to prevent 
introducing a breaking change.


Either way, in my estimation, handling this deprecation will - again - 
require not insignificant dev-time from maintainers to determine the 
best course of action for each flagged instance and to implement the 
changes, and what with the stagnation in OSS already happening, I wonder 
if now is the right time for adding this to their work-load, especially 
with the relatively flimsy argumentation for this RFC.


Let me finish by saying that I'm heartened to see the discussions here 
today, the addition to the RFC of the "Motivation" section and the ideas 
about a more gradual path, like mentioned by Derick and outlined by 
Larry and it gives me hope that the impact of these type of changes on 
OSS maintainers may be given more consideration in RFCs in the future.


With kind regards,
Juliette Reinders Folmer

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Chase Peeler]

On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown 
wrote:

> On Fri, 12 Nov 2021 at 08:08, Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I've opened the vote on
> > https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> > 2021-11-26.
> >
> > Regards,
> > Nikita
> >
>
> There are two things developers think about when releasing code:
>
> 1. does it work for me
> 2. does it work for everyone else
>
> With its support for runtime type hints and other similar checks, PHP does
> a reasonably good job of aligning those two — what works for me _generally_
> works for everyone else, too.
>
> Using dynamic properties is one of the areas where "works for me" and
> "works for everyone else" can diverge. Some people use static analysis to
> keep track of those divergences, but if PHP _can_ warn people they're doing
> a probably-dumb thing, I think it should.
>
>
Warning someone is very different than not allowing it


> I encourage people to vote "yes" on this, if you want PHP to be better at
> preventing people from shooting themselves in the foot.


What if I want a language where people can shoot themselves in the foot
because the flexibility it offers is what makes it great



> I know there are
> valid uses for this, but it's nevertheless a surprising feature, and not
> one that delights many PHP developers.


Why is this surprising? It's been available since classes were introduced
to PHP.


> Making it attribute-only from 9.0
> onwards seems incredibly sensible.
>
> Best wishes,
>
> Matt
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Matthew Brown]

On Fri, 12 Nov 2021 at 08:08, Nikita Popov  wrote:

> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita
>

There are two things developers think about when releasing code:

1. does it work for me
2. does it work for everyone else

With its support for runtime type hints and other similar checks, PHP does
a reasonably good job of aligning those two — what works for me _generally_
works for everyone else, too.

Using dynamic properties is one of the areas where "works for me" and
"works for everyone else" can diverge. Some people use static analysis to
keep track of those divergences, but if PHP _can_ warn people they're doing
a probably-dumb thing, I think it should.

I encourage people to vote "yes" on this, if you want PHP to be better at
preventing people from shooting themselves in the foot. I know there are
valid uses for this, but it's nevertheless a surprising feature, and not
one that delights many PHP developers. Making it attribute-only from 9.0
onwards seems incredibly sensible.

Best wishes,

Matt

[PHP-DEV] Archiving of PHP-SRC Security Backport Repository on Github

[Dale Hirt via internals]

Hello PHP Internals,

The PHP-SRC repository at 
https://github.com/microsoft/php-src
 has been used in the past to backport security fixes to 5.1 and 7.x.

The last commit in this repository was in August.  We have heard from that 
person that they no longer require the repository, and we have deprecated use 
of it internally as well.

On Monday, November 22nd, 2021, I will be archiving the repository.  This will 
set the repository to read-only, but will still make it available.

If you have any questions or concerns, please feel free to reach out to me.

Thank you,

Dale Hirt
Senior Service Engineer
Microsoft

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Chase Peeler]

On Mon, Nov 15, 2021 at 3:11 PM Deleu  wrote:

> By design my REST API utilizes dynamic properties. I've always found it to
>> be a feature of PHP, not a bug.
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>
> I am in the unfortunate position of inheriting a system with such REST API
> design. I can never build new REST APIs to replace the old ones because
> nobody can ever know how many combinations of possible input parameters
> there are.
>
>
Our inputs and outputs are both well defined. I've built a framework around
our entities that convert them into API payloads - attributes (symfony, but
eventually we might update it to use native attributes) define what fields
are visible based on user and whether it's the short (e.g. part of a
collection) or full version. The thing is that occasionally we'll have a
payload to return that requires additional attributes. Dynamic properties
allow us to just tack that on to the existing entity without having to
define it as a property on the entity (outside of the one use case the
property isn't needed and it definitely doesn't correspond to a database
column).



> --
> Marco Aurélio Deleu
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Björn Larsson via internals]

Den 2021-11-15 kl. 10:52, skrev Derick Rethans:

Dear Internals,

On Wed, 10 Nov 2021, Nikita Popov wrote:


On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov  wrote:


This RFC takes the more direct route of deprecating this
functionality entirely. I expect that this will have relatively
little impact on modern code (e.g. in Symfony I could fix the vast
majority of deprecation warnings with a three-line diff), but may
have a big impact on legacy code that doesn't declare properties at
all.



I plan to open voting on this RFC soon. Most of the feedback was
positive, apart from the initial choice of opt-int mechanism, and that
part should be addressed by the switch to the
#[AllowDynamicProperties] attribute.


The voting is now open, but I think one thing was not taken into account
here, the many small changes that push work to maintainers of Open
Source library and CI related tools.

In the last few years, the release cadence of PHP has increased, which
is great for new features. It however has not been helpful to introduce
many small deprecations and BC breaks in every single release.

This invariably is making maintainers of Open Source anxious, and
frustrated as so much work is need to keep things up to date. I know
they are *deprecations*, and applications can turn these off, but that's
not the case for maintainers of libraries.

Before we introduce many more of this into PHP 8.2, I think it would be
wise to figure out a way how to:

- improve the langauge with new features
- keep maintenance cost for open source library and CI tools much lower
- come up with a set of guidelines for when it is necessary to introduce
   BC breaks and deprecations.

I am all for improving the language and making it more feature rich, but
we have not spend enough time considering the impacts to the full
ecosystem.

I have therefore voted "no" on this RFC, and I hope you will too.

cheers,
Derick


Hi,

Maybe the RM's should have a mandate to keep track on deprecations for
a specific release and be able to say: "Sorry the shop are closed for
further deprecations in this release".

What do you think?

One could count the deprecations in the 8.x track and have a straw poll
on it and/or ask what key deprecations do we see further for the 8.x?

Is even the "Dynamic properties" one, one of the last ones?

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Björn Larsson via internals]

Den 2021-11-02 kl. 15:19, skrev Nikita Popov:

Hi internals,

The migration from bugs.php.net to GitHub issues has already been discussed
in https://externals.io/message/114300 and has already happened for
documentation issues.

I'd like to formally propose to use GitHub for PHP implementation issues as
well: https://wiki.php.net/rfc/github_issues

Regards,
Nikita


Hi,

The current proposal is to move all new issues from bugs.php.net to
Github except security ones.

I think it's important to think a bit on what that means for reporting
security issues in the future. I mean, if we leave bugs.php.net to rot 
in the corner, what are the consequences for reporting security issues?


I think that aspect needs to be a bit further analysed like:
- Will this move have a negative impact on reporting security issues
  on bugs.php.net?
  # Both from a technical and people perspective.
- Can one assume that by bugs.php.net having probably even less
  attention, that reporting security issues will work as is?
- Is there an alternative for also handling security issues?

Think it would be good if the RFC could analyse that a little, besides 
saying business as usual for security issues.


Regards //Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Deleu]

>
> By design my REST API utilizes dynamic properties. I've always found it to
> be a feature of PHP, not a bug.
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

I am in the unfortunate position of inheriting a system with such REST API
design. I can never build new REST APIs to replace the old ones because
nobody can ever know how many combinations of possible input parameters
there are.

-- 
Marco Aurélio Deleu

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Chase Peeler]

On Mon, Nov 15, 2021 at 3:02 PM James Gilliland  wrote:

> On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans  wrote:
>
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> > > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov 
> > wrote:
> > >
> > > > This RFC takes the more direct route of deprecating this
> > > > functionality entirely. I expect that this will have relatively
> > > > little impact on modern code (e.g. in Symfony I could fix the vast
> > > > majority of deprecation warnings with a three-line diff), but may
> > > > have a big impact on legacy code that doesn't declare properties at
> > > > all.
> > > >
> > >
> > > I plan to open voting on this RFC soon. Most of the feedback was
> > > positive, apart from the initial choice of opt-int mechanism, and that
> > > part should be addressed by the switch to the
> > > #[AllowDynamicProperties] attribute.
> >
> > The voting is now open, but I think one thing was not taken into account
> > here, the many small changes that push work to maintainers of Open
> > Source library and CI related tools.
> >
> > In the last few years, the release cadence of PHP has increased, which
> > is great for new features. It however has not been helpful to introduce
> > many small deprecations and BC breaks in every single release.
> >
> > This invariably is making maintainers of Open Source anxious, and
> > frustrated as so much work is need to keep things up to date. I know
> > they are *deprecations*, and applications can turn these off, but that's
> > not the case for maintainers of libraries.
> >
> > Before we introduce many more of this into PHP 8.2, I think it would be
> > wise to figure out a way how to:
> >
> > - improve the langauge with new features
> > - keep maintenance cost for open source library and CI tools much lower
> > - come up with a set of guidelines for when it is necessary to introduce
> >   BC breaks and deprecations.
> >
> > I am all for improving the language and making it more feature rich, but
> > we have not spend enough time considering the impacts to the full
> > ecosystem.
> >
> > I have therefore voted "no" on this RFC, and I hope you will too.
> >
> > cheers,
> > Derick
> >
>
> I appreciate that Derick. I know there have been some pretty big efforts
> required for some recent php updates in Drupal. And I've mentioned in a
> couple threads on Twitter but Drupal requires a pretty heavy change to
> support this. It adds properties to classes _outside_ its codebase which
> means none of the mitigations in the RFC apply. It was on my radar when the
> vote popped up because the system in question has long been known to be
> less than ideal but "php wouldn't ever remove this ancient feature right?"
> and every other option is just a ton more complicated. I've talked with
> some maintainers and it looks like we're going to deal with the cost of
> converting the system but if this dirty hack hadn't been on our radar it
> could have really hurt. Like maybe not getting the fix in place before the
> next major release in time for backwards compatibility commitments bad.
>
> So I worry what sort of earthquake this might trigger through libraries.
> Like, I'm pretty sure the OpenApiGenerator templates used dynamic
> properties for some things so how many little internal libraries are going
> to have to be regenerated? What other lightly maintained library are people
> going to be stuck waiting to update because someone's CI didn't catch the
> deprecation?
>

By design my REST API utilizes dynamic properties. I've always found it to
be a feature of PHP, not a bug.


>
> I think this sort of change is probably for the better, but I worry about
> how disruptive this could end up being.
>


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[James Gilliland]

On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans  wrote:

> Dear Internals,
>
> On Wed, 10 Nov 2021, Nikita Popov wrote:
>
> > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov 
> wrote:
> >
> > > This RFC takes the more direct route of deprecating this
> > > functionality entirely. I expect that this will have relatively
> > > little impact on modern code (e.g. in Symfony I could fix the vast
> > > majority of deprecation warnings with a three-line diff), but may
> > > have a big impact on legacy code that doesn't declare properties at
> > > all.
> > >
> >
> > I plan to open voting on this RFC soon. Most of the feedback was
> > positive, apart from the initial choice of opt-int mechanism, and that
> > part should be addressed by the switch to the
> > #[AllowDynamicProperties] attribute.
>
> The voting is now open, but I think one thing was not taken into account
> here, the many small changes that push work to maintainers of Open
> Source library and CI related tools.
>
> In the last few years, the release cadence of PHP has increased, which
> is great for new features. It however has not been helpful to introduce
> many small deprecations and BC breaks in every single release.
>
> This invariably is making maintainers of Open Source anxious, and
> frustrated as so much work is need to keep things up to date. I know
> they are *deprecations*, and applications can turn these off, but that's
> not the case for maintainers of libraries.
>
> Before we introduce many more of this into PHP 8.2, I think it would be
> wise to figure out a way how to:
>
> - improve the langauge with new features
> - keep maintenance cost for open source library and CI tools much lower
> - come up with a set of guidelines for when it is necessary to introduce
>   BC breaks and deprecations.
>
> I am all for improving the language and making it more feature rich, but
> we have not spend enough time considering the impacts to the full
> ecosystem.
>
> I have therefore voted "no" on this RFC, and I hope you will too.
>
> cheers,
> Derick
>

I appreciate that Derick. I know there have been some pretty big efforts
required for some recent php updates in Drupal. And I've mentioned in a
couple threads on Twitter but Drupal requires a pretty heavy change to
support this. It adds properties to classes _outside_ its codebase which
means none of the mitigations in the RFC apply. It was on my radar when the
vote popped up because the system in question has long been known to be
less than ideal but "php wouldn't ever remove this ancient feature right?"
and every other option is just a ton more complicated. I've talked with
some maintainers and it looks like we're going to deal with the cost of
converting the system but if this dirty hack hadn't been on our radar it
could have really hurt. Like maybe not getting the fix in place before the
next major release in time for backwards compatibility commitments bad.

So I worry what sort of earthquake this might trigger through libraries.
Like, I'm pretty sure the OpenApiGenerator templates used dynamic
properties for some things so how many little internal libraries are going
to have to be regenerated? What other lightly maintained library are people
going to be stuck waiting to update because someone's CI didn't catch the
deprecation?

I think this sort of change is probably for the better, but I worry about
how disruptive this could end up being.

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Arvids Godjuks]

On Wed, Aug 25, 2021 at 1:03 PM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
> https://wiki.php.net/rfc/deprecate_dynamic_properties
>
> This has been discussed in various forms in the past, e.g. in
> https://wiki.php.net/rfc/locked-classes as a class modifier and
> https://wiki.php.net/rfc/namespace_scoped_declares /
>
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md
> as a declare directive.
>
> This RFC takes the more direct route of deprecating this functionality
> entirely. I expect that this will have relatively little impact on modern
> code (e.g. in Symfony I could fix the vast majority of deprecation warnings
> with a three-line diff), but may have a big impact on legacy code that
> doesn't declare properties at all.
>
> Regards,
> Nikita
>

Hello everyone,
This is going to be a bit wordy, so sorry in advance, but I want to set the
context correctly.

As a userland developer, the overall idea concept I agree with, but the
thing that irks me here is that this is opt-out.

My day to day reality is dealing with complex big projects with codebases
that go into 5 digit file numbers excluding the ./vendor folder.
The projects are not legacy projects - they are being updated and are
actually run on 7.4 in E_ALL mode, we just finished upgrading it to Symfony
5.3
and are going to go full PHP8 soon. There are parts of the project that are
older style code and we update those as we go - we actually do have
tasks assigned to team members to specifically update the code, so it's
planned steady progress that has been going on for 2 years now.
We are not a small dev team too, but we also have our tasks to do features,
fix bugs and in general keep the system running and evolving.
Most our code is strict_types=1 and PHP 8 ready.

It is going to be a major undertaking that would halt all work to migrate
to a newer version of PHP where we need to inject the allow dynamic
attribute
without hitting a brick wall. It is not even going to be us, the
developers, who are going to have the biggest chunk of it - it's going to
be the QA who are
going to have to go through the whole project and identify all the issues
that crop up.
It is a complex and big piece of software that has been developed for the
past 10 years - there is no easy way to do one-shot big upgrades
 without prior planning way in advance. And while we can certainly deal
with it eventually (and stay on older PHP versions for a while)
all the 3rd party packages that we use are going to be an even bigger pain
to deal with and manage.

If a 3rd party package combines fixing major bugs with a release of a
significant version and including also the new attribute that's available
only on newer PHP version?
You end up in an "all-or-nothing" situation. I hope I do not have to
explain why this is not good?

This also goes against the general way PHP has been doing the strict stuff
- you opt-in into typed properties, arguments and return types. You also
opt-in into strict type mode.
Feels like this should follow the same approach.

If we are talking about having a blanket depreciation and then a fatal
error like that, I feel like it should be part of the
`declare(strict_types=1)` mode for the simple reason that
 most code in the wild is not really dynamic when the developer chooses to
run in strict mode (and a few cases where they need it - the RFC shows good
ways to convert the code).
Meaning chances of things breaking in a major way and requiring a lot of
work to update the code.
Automated tooling is nice if you know you can safely do "all or nothing".
In complex systems that are ongoing projects where you have to balance
progress with upgrading older parts it's rarely that simple.

Something to think about and my 0.02$ on the subject.

-- 

Arvīds Godjuks
+371 26 851 664
arvids.godj...@gmail.com
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Dan Ackroyd]

On Mon, 15 Nov 2021 at 09:47, Derick Rethans  wrote:

Derick wrote:
> I think it is a mistake to decide on a whim to move over to GitHub
> issues without having evaluated anything else.

Maybe avoid being insulting about other people's decision making
process? I'm pretty sure that Nikita doesn't make that many decisions
on a whim, and that he has spent quite a bit of time over the past
couple of weeks/months figuring out how it would work, and getting a
test repo setup with the new issue templates.

And I also believe he has spent signification time evaluating
alternatives, but they all come up across the same problem listed in
the RFC:

"The requirement for an alternative would be that a) it is hosted
(i.e. the PHP project does not need to maintain infrastructure for
it), b) has good GitHub integration and c) is “sufficiently better”
than GitHub issues to make it worth using a separate product."

I don't think the vendor lock-in concern is that great. If Microsoft
actually starts acting evil again, to the extent that we need to stop
using Github for either code or issues, then we would be able to move
again. The lock-in on github doesn't appear to be worse than
bugs.php.net. In fact, it's far more likely that anything we would
move to is going to have an "import from github" button, than anything
having an "import from bugs.php.net" button.

> This jump to GitHub Issues feels rushed,

The topic has been discussed for at least 6 months:
https://news-web.php.net/php.internals/114330

That seems like quite a bit of time for people who would prefer to
avoid github to evaluate the alternatives and write out a plan.

cheers
Dan
Ack

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Dan Ackroyd]

On Mon, 15 Nov 2021 at 09:56, Hans Henrik Bergan  wrote:
>
> if hosting it ourself is a priority,

No, quite the opposite.

The PHP project is pretty terrible at running infrastructure, as
infrastructure needs to have people available to work on it
immediately when there are issues, which is not a good match a
volunteer project. There is also the problem that a lot of maintenance
needed for sites (or things like PEAR/PECL) are very boring, and so
they are allowed to rot for years.

Even if we had the resources to host something ourselves, doing so
would come at an opportunity cost of not doing something that provides
better value for the time.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Marco Pivetta]

Chiming in, since it seems like people are suggesting Gitlab and further
"exotic" tools.

On Mon, Nov 15, 2021 at 6:06 PM Rowan Tommins 
wrote:

> On 15/11/2021 14:49, Deleu wrote:
> > I had already decided to spend time and effort learning about the
> > project and then having to learn about their ticketing system and git
> > repository is just unnecessary extra work.
>
>
> In any project above a handful of developers, learning the conventions
> and expectations of the community is always going to be far more
> complicated than learning how to use the actual tools in question. We
> should definitely choose a tool that is *easy to use*, and easy to
> authenticate on (but not so easy it fills up with spam, like the current
> one), but saying that developers will struggle to use anything other
> than the One True Website is frankly insulting to the intelligence of
> the average developer.
>
>
The point of using Github (over other tools) is:

 * the community is already there
 * the repository is already frikken there
 * it's about pumping stuff into the issue tracker, nothing new is added
 * integrated CVE reports that already fit within the ecosystem
 * 2fa auth requirement for organization members (gitlab has this too,
AFAIK, but it's a checkbox to add somewhere)
 * including pre-existing users in discussions (yes, leading to pings),
even those that didn't declare a public mail - no registration and no GDPR
to manage on PHP-SRC's end
 * rich editing of issues, with code fragments from the repo, rather than
copy-pasta'd stuff all over the place
 * cross-linking of PHP sources with other project sources, including
backlink references that make bugs and workarounds easier to follow by
community members

This stuff is not to be under-estimated: going self-hosted means having yet
another insular environment, where the PHP-SRC folks are trapped in a bit
of a void, and the actual discussions will keep happening on PHP-SRC diffs
anyway.

Instead of fearing the "One True Website", adopt and plan for disaster,
should it become an Evil Corp seeding ground: what is there to be lost, and
how hard would it be to recover?

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Larry Garfield]

On Mon, Nov 15, 2021, at 10:52 AM, Rowan Tommins wrote:
> On 15/11/2021 16:23, Andreas Heigl wrote:
>> One thing, that can verify the correct working of properties, whether 
>> that is dynamic or static ones, is testing.
>
>
> Can it? I can't actually see how that would work, without also having a 
> way to detect when dynamic properties were accessed, which brings us 
> full circle. Also:
>
>
>> So the mistakes-part would be easy to handle. 
>
> If you are working with a million lines of code going back 20 years, 
> "write tests for everything" is not "easy to handle"; it's a long-term 
> ambition which you chip away at when priorities allow.
>
> "Logging all deprecations and warnings on a production workload", 
> however, *is* easy to handle. Diagnostic messages in logs are the *only* 
> way this behaviour will be spotted in old code.
>
>
>> What I am still missing is the differentiation between "everything is 
>> strict and you have to explicitly opt-in to make it dynamic" and an 
>> "everything is dynamic and you can use a marker to mark this 
>> explicitly an intended behaviour". That would allow users to mark a 
>> class explicitly to use dynamic features even though it would make no 
>> difference code-wise.
>
>
> I'm not sure what you mean by that. Do you mean, create the attribute, 
> but don't actually do anything with it? Would the plan be to deprecate 
> later? Never remove at all?

A possible idea to help make this transition (which I do support) more gradual:

Instead of an "allow" attribute, introduce a boolean flag attribute.  

#[DynamicProperties(true)]
class Beep {}

The attribute marks whether dynamic properties are enabled or disabled via 
boolean.  If disabled, then they're an error if used.

8.2: Introduce the attribute, with a default of TRUE.  Exactly zero code 
breaks, but people can start adding the attribute now.  That means people who 
want to lock-out dynamic properties can do so starting now, and those cases 
that do need them (or can't easily get away from them) can be flagged far in 
advance.
8.something: Change the default to FALSE.  Using dynamic properties when false 
throws a deprecation, not an error.  People have had some number of years to 
add the attribute either direction if desired.
9.0: Change the deprecation to an error, if the attribute is set false (which 
by now is the default) and dynamic properties are used.
Sometime in the future: Setting the attribute to true triggers a deprecation.
Sometime in the future: Remove dynamic properties entirely, and the attribute 
along with it.  People can use __get/__set if they really need.

This still gets us to the same place in the end, but introduces another stage 
along the way to make the transition more gradual.  We can debate which version 
the default should flip in, I don't much mind.  That could even wait for 9 if 
we want to be really really gradual about it.

Meanwhile, IDEs and code templates can start including the attribute set to 
false by default on any new classes that get written, just like they have done 
for years with strict types.

Nikita, would that be feasible?  Matthew, Derick, would that be satisfactory?

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Andreas Heigl]

Hey Rowan, hey all

On 15.11.21 17:52, Rowan Tommins wrote:

On 15/11/2021 16:23, Andreas Heigl wrote:
One thing, that can verify the correct working of properties, whether 
that is dynamic or static ones, is testing.



Can it? I can't actually see how that would work, without also having a 
way to detect when dynamic properties were accessed, which brings us 
full circle. Also:


When you are testing whether writing 'X' to a property and then reading 
from that property gives that 'X' back, then everything should be good.


You either typed the name of the property correctly or you have a typo 
in the setter and getter (or however you set and got the value). 
Nevertheless you should be able to figure out whether you accidentally 
misstyped a property name somewhere as that should break the test 
(unless you misstyped the name twice). ANd whether you are doing the 
assignement to a static property or to a dynamic one should be 
irrelevant, the reading and the writing process are the same.


Yes: That rips off a completely different topic: Testing "getters" and 
"setters".


So the mistakes-part would be easy to handle. 


If you are working with a million lines of code going back 20 years, 
"write tests for everything" is not "easy to handle"; it's a long-term 
ambition which you chip away at when priorities allow.


The intention is not to write tests for existing code. As the intention 
is exactly to be able to leave existing code as it is. Otherwise the 
approach to "add the Attribute and be done" would be much easier.


The intention is much more to make sure that *new* code does not write 
accidentally to the wrong property. Which is what this RFC is all about. 
Make sure that dynamic properties are not accidentally used.


"Logging all deprecations and warnings on a production workload", 
however, *is* easy to handle. Diagnostic messages in logs are the *only* 
way this behaviour will be spotted in old code.


That is absolutely correct. The main question is: "Do we *need* to spot 
this behaviour in old code"? Not "Do we *want* to spot this behaviour in 
old code".



What I am still missing is the differentiation between "everything is 
strict and you have to explicitly opt-in to make it dynamic" and an 
"everything is dynamic and you can use a marker to mark this 
explicitly an intended behaviour". That would allow users to mark a 
class explicitly to use dynamic features even though it would make no 
difference code-wise.



I'm not sure what you mean by that. Do you mean, create the attribute, 
but don't actually do anything with it? Would the plan be to deprecate 
later? Never remove at all?
As currently there is no direct intention to remove the feature for 
good, why should we force it? And espechialy why do we need to force 
those maintinaing existing code to adapt their code?


For now the possibility could be to keep everything *as is*. Plus add an 
attribute to make absolutely explicit that we want to use this feature.
The next step could then be to create a setting that will notify about 
dynamic assignments in classes that are not marked by the attribute. I'm 
not talking about a deprecation note here. More something like a notice 
(not a warning as that is too severe!). That way the behaviour can come 
up in log files. Perhaps a new Level of notice like a 
"bad_coding_practice". Or we use different "lanes" of reporting. One for 
notices, errors, warnings et al and one for deprecations and such 
asignment-oddities.
When that has been done (should so far all be BC) and code-maintainers 
have had enough time to modify their codebase (definition of "enough 
time" is here clearly the main topic and needs discussion with 
maintainers!) then we can talk about possibly phasing out the feature.


My 0.02€

Cheers

Andreas
--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+


OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Rowan Tommins]

On 15/11/2021 14:49, Deleu wrote:

I had already decided to spend time and effort learning about the
project and then having to learn about their ticketing system and git
repository is just unnecessary extra work.



In any project above a handful of developers, learning the conventions 
and expectations of the community is always going to be far more 
complicated than learning how to use the actual tools in question. We 
should definitely choose a tool that is *easy to use*, and easy to 
authenticate on (but not so easy it fills up with spam, like the current 
one), but saying that developers will struggle to use anything other 
than the One True Website is frankly insulting to the intelligence of 
the average developer.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Côme Chilliet]

Le lundi 15 novembre 2021, 15:49:04 CET Deleu a écrit :
> Gitlab is not where the wide PHP Community is located. Composer,
> widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs
> are all hosted on GitHub. Choosing something else increases the barrier for
> newcomers to become contributors. I speak from experience that when I tried
> to contribute to Alpine Linux, one of the major turn off was GitLab
> hosting. I had already decided to spend time and effort learning about the
> project and then having to learn about their ticketing system and git
> repository is just unnecessary extra work.

This is exactly the problem with moving to Github, we are forcing everyone to 
come with us, as others are inciting us to go there by being there (composer, 
…).
Then people only know how to use Github and we are stuck there forever.

If we survived all these years with bugs.php.net, we should be alright with 
gitlab for sure.

I think the PHP project could lead the way out of github instead of following 
the others in.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[James Gilliland]

On Mon, Nov 15, 2021 at 8:49 AM Deleu  wrote:

> >
> >
> > I would like to suggest gitlab.com, which does provide hosting for free
> > for opensource projects: https://about.gitlab.com/solutions/open-source/
> > Anyone with a github account can use it to log in.
> > It should be easy to migrate to any other gitlab instance if needed.
> There
> > are even plans to one day have federation over gitlab instances. Not
> > anytime soon, but likely sooner than github which is only hosted by
> > Microsoft.
> >
> > Côme
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
> Gitlab is not where the wide PHP Community is located. Composer,
> widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs
> are all hosted on GitHub. Choosing something else increases the barrier for
> newcomers to become contributors. I speak from experience that when I tried
> to contribute to Alpine Linux, one of the major turn off was GitLab
> hosting. I had already decided to spend time and effort learning about the
> project and then having to learn about their ticketing system and git
> repository is just unnecessary extra work.
>
> PHP should not distance itself from its user base.
>
>
Drupal Is currently in the process of migrating to a self hosted Gitlab
instance. For some of the reasons highlighted by Derick but also because
Github's issues and collaboration can be pretty terrible. There's hints of
issue improvements on the horizon but we'll see. Gitlab however has been
great in collaborating with us in addressing issues and collaborating on
supporting our credit system.

My impression is that Gnome switched because of the level of support and
interest in Open Source communities so I wouldn't  write them off without
taking a look.

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Rowan Tommins]

On 15/11/2021 16:23, Andreas Heigl wrote:
One thing, that can verify the correct working of properties, whether 
that is dynamic or static ones, is testing.



Can it? I can't actually see how that would work, without also having a 
way to detect when dynamic properties were accessed, which brings us 
full circle. Also:



So the mistakes-part would be easy to handle. 


If you are working with a million lines of code going back 20 years, 
"write tests for everything" is not "easy to handle"; it's a long-term 
ambition which you chip away at when priorities allow.


"Logging all deprecations and warnings on a production workload", 
however, *is* easy to handle. Diagnostic messages in logs are the *only* 
way this behaviour will be spotted in old code.



What I am still missing is the differentiation between "everything is 
strict and you have to explicitly opt-in to make it dynamic" and an 
"everything is dynamic and you can use a marker to mark this 
explicitly an intended behaviour". That would allow users to mark a 
class explicitly to use dynamic features even though it would make no 
difference code-wise.



I'm not sure what you mean by that. Do you mean, create the attribute, 
but don't actually do anything with it? Would the plan be to deprecate 
later? Never remove at all?


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Andreas Heigl]

Hey Nikita.

On 15.11.21 14:50, Nikita Popov wrote:

[...]
I hope that the new "Motivation" section clarifies things a bit, especially
in regards to why "static analysis" is only a partial solution to this
problem: https://wiki.php.net/rfc/deprecate_dynamic_properties#motivation


Thanks for the clarification!

One thing, that can verify the correct working of properties, whether 
that is dynamic or static ones, is testing. So when one wants to make 
sure that their code behaves as it should, then proper testing can help 
with that. So while the static analysis is one possibility, the other 
one is writing appropriate tests. While that will still not eliminate 
the usage of external tools it is fore sure something that most of the 
projects using modern code already implement.


So the mistakes-part would be easy to handle.

Being explicit on the other hand is something that I would very much 
appreciate. And using an Annotation for that is great. What I am still 
missing is the differentiation between "everything is strict and you 
have to explicitly opt-in to make it dynamic" and an "everything is 
dynamic and you can use a marker to mark this explicitly an intended 
behaviour". That would allow users to mark a class explicitly to use 
dynamic features even though it would make no difference code-wise.


And that could already be implemented via a userland-shim right now 
which would then use the Core-Attribute as of PHP8.2


The other thing, that I noticed is that you were speaking of a possible 
reduction of the object-size by 8 byte. Is there a comparison of how 
much that would be in percent for some default applications? So is that 
something that actually "pays off"?


Thanks again for your insights!

Cheers

Andreas
--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+


OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Deleu]

>
>
> I would like to suggest gitlab.com, which does provide hosting for free
> for opensource projects: https://about.gitlab.com/solutions/open-source/
> Anyone with a github account can use it to log in.
> It should be easy to migrate to any other gitlab instance if needed. There
> are even plans to one day have federation over gitlab instances. Not
> anytime soon, but likely sooner than github which is only hosted by
> Microsoft.
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Gitlab is not where the wide PHP Community is located. Composer,
widely-used and adopted packages, frameworks, PSRs, PHP itself and PHP Docs
are all hosted on GitHub. Choosing something else increases the barrier for
newcomers to become contributors. I speak from experience that when I tried
to contribute to Alpine Linux, one of the major turn off was GitLab
hosting. I had already decided to spend time and effort learning about the
project and then having to learn about their ticketing system and git
repository is just unnecessary extra work.

PHP should not distance itself from its user base.
-- 
Marco Aurélio Deleu

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Côme Chilliet]

I strongly agree with Derick on this matter.

Le lundi 15 novembre 2021, 12:06:54 CET Nikita Popov a écrit :
> For better or worse, GitHub is where nearly all open-source projects are
> hosted, which means that pretty much anyone involved in open-source has an
> account there and is familiar with the workflows. 

I do think that this is for worse, and that this situation exists because of 
decision like the one PHP is about to make. Saying we should use github because 
other projects use it is part of the problem. If PHP makes the switch we are 
encouraging other projects to do the same as well. We would be actively 
participating in this centralisation.

> It is also where PHP
> hosts it's repos and where we accept pull requests. 

Which I also think is a problem. A smaller one because of how git is 
distributed, but still annoying. The decision to move to github for the 
repositories was done in a hurry because of a security issue. It was the right 
decision to answer to the urgency of the situation back then I think, but it 
should not be used as a reason to go deeper down the rabbit hole.

> An alternative issue
> tracker has to compete not just on technical grounds, but also on
> integration, familiarity and network-effect. For an open-source project,
> these aspects are quite important when it comes to interaction with casual
> contributors.
> 
> Working at JetBrains, proposing YouTrack instead of GH issues has certainly
> crossed my mind -- there is no doubt that at a technical level, it's a much
> better bug tracker than GH issues. But that's simply not the right question
> to ask. The right question is whether, given our rather simple
> requirements, is it sufficiently better to overshadow the other benefits of
> GitHub issues for an open-source project? I don't think so. We just need GH
> issues to be "good enough" for our purposes, and I think that at this point
> it is.
> 
> I'll also mention that the discussion about this migration has been going
> on for six months, and in that time all I've ever seen are vague mentions
> of alternatives, but nobody has provided any in-depth analysis that goes
> beyond a simple name drop. I went through the trouble of providing a
> detailed evaluation of how the GitHub issues migration will look like,
> while the alternatives are still at the state of "Phabricator is a thing"
> (ooops, it actually isn't -- it managed to be discontinued while the
> discussion was going on!)

I would like to suggest gitlab.com, which does provide hosting for free for 
opensource projects: https://about.gitlab.com/solutions/open-source/
Anyone with a github account can use it to log in.
It should be easy to migrate to any other gitlab instance if needed. There are 
even plans to one day have federation over gitlab instances. Not anytime soon, 
but likely sooner than github which is only hosted by Microsoft.

Côme

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Alexandru Pătrănescu]

On Mon, Nov 15, 2021 at 2:52 PM Andreas Heigl  wrote:

>
> And as far as I can see from the PR associated with this RFC it will not
> make life easier for the internals team. It is not like there will be
> hundreds of lines code less to maintain. On the contrary. There is more
> code and more logic to maintain [2].
>

Sometimes it  needs to be worse until it's better.
Some points that evolved during discussion also mentioned the intention of
how easy to allow it to be to opt-in and in the end the attribute was
chosen as the easiest one.
Even if the intention was to simplify the code to maintain, it was not
clear how much PHP users would want to stay without this feature.
And the problem was that using the attribute, it would not be easy to
remove it in PHP 9.
But at least it would give a better sense of usage once we get to PHP 9 so
it can be completely removed only in PHP 10+ or to use a more strict
opt-in mechanism.

So yes, you are right, having it like this would make the code a bit worse
to maintain for 8 years and easier to maintain after that, if I got it
right.

But the benefit related to the dynamic properties bugs reduction would be
seen in userland starting with PHP 8.2.

Regards,
Alex

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Nikita Popov]

On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl  wrote:

> Hea all.
>
> On 15.11.21 10:52, Derick Rethans wrote:
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> >> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov 
> wrote:
> >>
> >>> This RFC takes the more direct route of deprecating this
> >>> functionality entirely. I expect that this will have relatively
> >>> little impact on modern code (e.g. in Symfony I could fix the vast
> >>> majority of deprecation warnings with a three-line diff), but may
> >>> have a big impact on legacy code that doesn't declare properties at
> >>> all.
> >>>
> >>
> >> I plan to open voting on this RFC soon. Most of the feedback was
> >> positive, apart from the initial choice of opt-int mechanism, and that
> >> part should be addressed by the switch to the
> >> #[AllowDynamicProperties] attribute.
> >
> > The voting is now open, but I think one thing was not taken into account
> > here, the many small changes that push work to maintainers of Open
> > Source library and CI related tools.
> >
> > In the last few years, the release cadence of PHP has increased, which
> > is great for new features. It however has not been helpful to introduce
> > many small deprecations and BC breaks in every single release.
> >
> > This invariably is making maintainers of Open Source anxious, and
> > frustrated as so much work is need to keep things up to date. I know
> > they are *deprecations*, and applications can turn these off, but that's
> > not the case for maintainers of libraries.
> >
> > Before we introduce many more of this into PHP 8.2, I think it would be
> > wise to figure out a way how to:
> >
> > - improve the langauge with new features
> > - keep maintenance cost for open source library and CI tools much lower
> > - come up with a set of guidelines for when it is necessary to introduce
> >BC breaks and deprecations.
> >
> > I am all for improving the language and making it more feature rich, but
> > we have not spend enough time considering the impacts to the full
> > ecosystem.
> >
> > I have therefore voted "no" on this RFC, and I hope you will too.
> >
> > cheers,
> > Derick
>
> After some thoughs on this RFC I have reverted my original vote and
> voted "No" due to several reasons.
>
> For one thing it is not clear to me what the benefits are.
>

That's my bad! The RFC did not really go into the motivation for the
change, especially after I dropped the discussion of internal motivations
in a later revision.

I hope that the new "Motivation" section clarifies things a bit, especially
in regards to why "static analysis" is only a partial solution to this
problem: https://wiki.php.net/rfc/deprecate_dynamic_properties#motivation

Regards,
Nikita

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Benjamin Eberlei]

On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl  wrote:

> Hea all.
>
> On 15.11.21 10:52, Derick Rethans wrote:
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> >> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov 
> wrote:
> >>
> >>> This RFC takes the more direct route of deprecating this
> >>> functionality entirely. I expect that this will have relatively
> >>> little impact on modern code (e.g. in Symfony I could fix the vast
> >>> majority of deprecation warnings with a three-line diff), but may
> >>> have a big impact on legacy code that doesn't declare properties at
> >>> all.
> >>>
> >>
> >> I plan to open voting on this RFC soon. Most of the feedback was
> >> positive, apart from the initial choice of opt-int mechanism, and that
> >> part should be addressed by the switch to the
> >> #[AllowDynamicProperties] attribute.
> >
> > The voting is now open, but I think one thing was not taken into account
> > here, the many small changes that push work to maintainers of Open
> > Source library and CI related tools.
> >
> > In the last few years, the release cadence of PHP has increased, which
> > is great for new features. It however has not been helpful to introduce
> > many small deprecations and BC breaks in every single release.
> >
> > This invariably is making maintainers of Open Source anxious, and
> > frustrated as so much work is need to keep things up to date. I know
> > they are *deprecations*, and applications can turn these off, but that's
> > not the case for maintainers of libraries.
> >
> > Before we introduce many more of this into PHP 8.2, I think it would be
> > wise to figure out a way how to:
> >
> > - improve the langauge with new features
> > - keep maintenance cost for open source library and CI tools much lower
> > - come up with a set of guidelines for when it is necessary to introduce
> >BC breaks and deprecations.
> >
> > I am all for improving the language and making it more feature rich, but
> > we have not spend enough time considering the impacts to the full
> > ecosystem.
> >
> > I have therefore voted "no" on this RFC, and I hope you will too.
> >
> > cheers,
> > Derick
>
> After some thoughs on this RFC I have reverted my original vote and
> voted "No" due to several reasons.
>
> For one thing it is not clear to me what the benefits are. Yes: The
> language evolution RFC talks about "Forbidding dynamic object
> properties" but it also specifies that "there is also a lot of old code
> that does not declare properties, so this needs to be opt-in"[1].
>
> And as far as I can see from the PR associated with this RFC it will not
> make life easier for the internals team. It is not like there will be
> hundreds of lines code less to maintain. On the contrary. There is more
> code and more logic to maintain [2].
>

This RFCs goal is not to have less code to maintain, but to fix a nasty
class of errors in user errors where they accidently write/read to a
dynamic property due to a typo, instead of accessing the declared one.

True this is a mistake of the RFC not to highlight more.


> So when the only reason for the change is that one line in the RFC ("In
> modern code, this is rarely done intentionally"[3]) then that is not
> enough of a reasoning for me for such a code change that requires a lot
> of existing code to change.
>
> Those that want a cleaner code can already use static code analysis to
> find such issues (if not, I'm sure that there will be some analyzers
> around before PHP8.2 will be around) or write appropriate tests to make
> sure that they do not use undeclared properties.
>

Code that intentionally or unintentionally uses dynamic properties often
does not write each propery explicitly:

$object->$columnName = $value;

This cannot be detected by static analysers.

For the case where you explitly write a property name, While static
analysis and IDEs do help detecing these as problems, this class of bugs
happens because you are *not* using an IDE but a text editor like
Vim/Notepad++ where you maybe add a typo to a property name while writing
code.


> While I personally would really like to deprecate dynamic properties I
> believe that it is the wrong thing to do for the language. At least
> given the presented arguments why we should do it.
>
> Cheers
>
> Andreas
>
> PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in
> the RFC?
>
>
>
> [1]
>
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md#forbidding-dynamic-object-properties
> [2] https://github.com/php/php-src/pull/7571/files
> [3] https://wiki.php.net/rfc/deprecate_dynamic_properties
>
> --
>,,,
>   (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Andreas Heigl]

On 15.11.21 14:19, Rowan Tommins wrote:

On 15/11/2021 12:51, Andreas Heigl wrote:
PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in 
the RFC? 



All votes require a 2/3 majority as of 
https://wiki.php.net/rfc/abolish-narrow-margins


Thanks!

I just stumbled over the fact that some other recent RFCs still had the 
statement "requiring a 2/3 majority" in the "Vote" part which I was 
missing here.


Cheers

Andreas
--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+


OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Rowan Tommins]

On 15/11/2021 12:51, Andreas Heigl wrote:
PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in 
the RFC? 



All votes require a 2/3 majority as of 
https://wiki.php.net/rfc/abolish-narrow-margins



--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Finer control of diagnostics (deprecations, notices, and warnings)

[Rowan Tommins]

On 15/11/2021 12:03, Michał Marcin Brzuchalski wrote:
Personally, I think that given feature users would add whole vendor 
directory,

since the vendor/package directory is not fixed,
may change - which in essence may go out of control and silently 
invoke a waterfall of unexpected errors.



I don't understand your concern; possibly you have misunderstood my 
suggestion?


I'm saying that a user who wants to see if they are using deprecated 
features in their own code would want to turn on E_DEPRECATED in their 
main error_reporting, but turn it OFF for all third-party code. Most of 
the time, deprecation notices in third-party code are not useful to 
users: they are not responsible for fixing them in advance, and when 
actually switching major PHP version, they may have to switch to a 
different major release of the library before testing anyway.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Andreas Heigl]

Hea all.

On 15.11.21 10:52, Derick Rethans wrote:

Dear Internals,

On Wed, 10 Nov 2021, Nikita Popov wrote:


On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov  wrote:


This RFC takes the more direct route of deprecating this
functionality entirely. I expect that this will have relatively
little impact on modern code (e.g. in Symfony I could fix the vast
majority of deprecation warnings with a three-line diff), but may
have a big impact on legacy code that doesn't declare properties at
all.



I plan to open voting on this RFC soon. Most of the feedback was
positive, apart from the initial choice of opt-int mechanism, and that
part should be addressed by the switch to the
#[AllowDynamicProperties] attribute.


The voting is now open, but I think one thing was not taken into account
here, the many small changes that push work to maintainers of Open
Source library and CI related tools.

In the last few years, the release cadence of PHP has increased, which
is great for new features. It however has not been helpful to introduce
many small deprecations and BC breaks in every single release.

This invariably is making maintainers of Open Source anxious, and
frustrated as so much work is need to keep things up to date. I know
they are *deprecations*, and applications can turn these off, but that's
not the case for maintainers of libraries.

Before we introduce many more of this into PHP 8.2, I think it would be
wise to figure out a way how to:

- improve the langauge with new features
- keep maintenance cost for open source library and CI tools much lower
- come up with a set of guidelines for when it is necessary to introduce
   BC breaks and deprecations.

I am all for improving the language and making it more feature rich, but
we have not spend enough time considering the impacts to the full
ecosystem.

I have therefore voted "no" on this RFC, and I hope you will too.

cheers,
Derick


After some thoughs on this RFC I have reverted my original vote and 
voted "No" due to several reasons.


For one thing it is not clear to me what the benefits are. Yes: The 
language evolution RFC talks about "Forbidding dynamic object 
properties" but it also specifies that "there is also a lot of old code 
that does not declare properties, so this needs to be opt-in"[1].


And as far as I can see from the PR associated with this RFC it will not 
make life easier for the internals team. It is not like there will be 
hundreds of lines code less to maintain. On the contrary. There is more 
code and more logic to maintain [2].


So when the only reason for the change is that one line in the RFC ("In 
modern code, this is rarely done intentionally"[3]) then that is not 
enough of a reasoning for me for such a code change that requires a lot 
of existing code to change.


Those that want a cleaner code can already use static code analysis to 
find such issues (if not, I'm sure that there will be some analyzers 
around before PHP8.2 will be around) or write appropriate tests to make 
sure that they do not use undeclared properties.


While I personally would really like to deprecate dynamic properties I 
believe that it is the wrong thing to do for the language. At least 
given the presented arguments why we should do it.


Cheers

Andreas

PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in 
the RFC?




[1] 
https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md#forbidding-dynamic-object-properties

[2] https://github.com/php/php-src/pull/7571/files
[3] https://wiki.php.net/rfc/deprecate_dynamic_properties

--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+


OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Kamil Tekiela]

I would be very sad to see this RFC not go through. I have voted Yes as I
believe this "feature":is a bug that needs to be fixed. There is also an
opt-in proposed for people who really do consider it a feature.

I don't see why it would cause much trouble for maintainers of OSS. At the
moment it is proposed to make this change in PHP 9.0, which is a couple
years away. That is a lot of time to fix the code. The deprecation message
will inform us about the number of uses, whether accidental or intentional.
If we decide that removal of this feature would cause too much disruption,
could we not have RFC in PHP 8.3 to remove the deprecation?

Deprecated or not, I still believe that OSS should avoid dynamic
properties. They are really difficult to identify, even with static
analysers. Having the deprecation message would at least help us identify
where dynamic properties were used, so that we can fix it.

Re: [PHP-DEV] Finer control of diagnostics (deprecations, notices, and warnings)

[Michał Marcin Brzuchalski]

pon., 15 lis 2021 o 13:03 Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> napisał(a):

> Hi Rowan,
>
> pon., 15 lis 2021 o 12:34 Rowan Tommins 
> napisał(a):
>
>> Hi all,
>>
>> Concerns have been raised a few times recently about adding new warnings
>> and deprecation notices, particularly:
>>
>> * That code bases with many instances of a particular pattern see a lot
>> of noise when a message is added
>> * That library maintainers face pressure to fix deprecations from users
>> who don't want to see those messages in their logs
>>
>> I don't think "stop adding new diagnostics to PHP" is a good solution to
>> these problems, and have thought of two ideas which might improve
>> things; both need refinement, but I hope can at least act as discussion
>> starters.
>>
>>
>> The first idea is directory-level error_reporting configuration.
>>
>> In principle, this would be very simple: a mechanism (ini setting or
>> function) that lets a user specify a different error_reporting level for
>> all code compiled from a particular directory. The most common use I
>> foresee is reducing reporting in third-party libraries, e.g.
>>
>> error_reporting=E_ALL
>> error_reporting[*/vendor/*]=E_ERROR+E_WARNING
>>
>
> IMO this screams for comments regarding
> modules/packages/assemblies however called
> where error_reporting could be controlled by vendors.
> Personally, I think that given feature users would add whole vendor
> directory,
> since the vendor/package directory is not fixed,
> may change - which in essence may go out of control and silently invoke a
> waterfall of unexpected errors.
>
>
>> This would hopefully reduce pressure on maintainers to fix deprecation
>> notices as soon as they appear, because they would no longer be
>> cluttering the user's logs.
>>
>>
>> The second idea is diagnostic codes or categories.
>>
>> This is more complicated, because it requires classifying all existing
>> diagnostics to add extra information, but would allow users to act
>> differently on specific messages. They might suppress them, downgrade
>> Warnings to Notices, or even upgrade Notices to Warnings - as they might
>> with rules in an IDE or Static Analysis tool.
>>
>> As an extension, the @ operator could be enhanced to suppress a specific
>> diagnostic, so that the following would give an "undefined variable"
>> warning, but be silent about the file not existing:
>>
>> @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');
>>
>
> This proposal allows to silence errors in certain statements but instead
> of extending silence operator
> personally, I'd prefer to enable statement-level attributes and shape them
> in an opt-in manner.
> Instead of proposing new syntax backward incompatible like this:
>
> $fp = @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');
>
> introduce statement level attributes which can be backward compatible when
> in one line
>
> $fp =
> #[SupressErrors(E_WARNING)]
> fopen($undefinedVariable, 'r');
>

My apologies this won't work for 8.0 and 8.1 since there are no
statement-level
attributes and the online attribute as a comment hack works only for <8.0
versions.

Regards,

Re: [PHP-DEV] Finer control of diagnostics (deprecations, notices, and warnings)

[Michał Marcin Brzuchalski]

Hi Rowan,

pon., 15 lis 2021 o 12:34 Rowan Tommins 
napisał(a):

> Hi all,
>
> Concerns have been raised a few times recently about adding new warnings
> and deprecation notices, particularly:
>
> * That code bases with many instances of a particular pattern see a lot
> of noise when a message is added
> * That library maintainers face pressure to fix deprecations from users
> who don't want to see those messages in their logs
>
> I don't think "stop adding new diagnostics to PHP" is a good solution to
> these problems, and have thought of two ideas which might improve
> things; both need refinement, but I hope can at least act as discussion
> starters.
>
>
> The first idea is directory-level error_reporting configuration.
>
> In principle, this would be very simple: a mechanism (ini setting or
> function) that lets a user specify a different error_reporting level for
> all code compiled from a particular directory. The most common use I
> foresee is reducing reporting in third-party libraries, e.g.
>
> error_reporting=E_ALL
> error_reporting[*/vendor/*]=E_ERROR+E_WARNING
>

IMO this screams for comments regarding
modules/packages/assemblies however called
where error_reporting could be controlled by vendors.
Personally, I think that given feature users would add whole vendor
directory,
since the vendor/package directory is not fixed,
may change - which in essence may go out of control and silently invoke a
waterfall of unexpected errors.


> This would hopefully reduce pressure on maintainers to fix deprecation
> notices as soon as they appear, because they would no longer be
> cluttering the user's logs.
>
>
> The second idea is diagnostic codes or categories.
>
> This is more complicated, because it requires classifying all existing
> diagnostics to add extra information, but would allow users to act
> differently on specific messages. They might suppress them, downgrade
> Warnings to Notices, or even upgrade Notices to Warnings - as they might
> with rules in an IDE or Static Analysis tool.
>
> As an extension, the @ operator could be enhanced to suppress a specific
> diagnostic, so that the following would give an "undefined variable"
> warning, but be silent about the file not existing:
>
> @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');
>

This proposal allows to silence errors in certain statements but instead of
extending silence operator
personally, I'd prefer to enable statement-level attributes and shape them
in an opt-in manner.
Instead of proposing new syntax backward incompatible like this:

$fp = @{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');

introduce statement level attributes which can be backward compatible when
in one line

$fp =
#[SupressErrors(E_WARNING)]
fopen($undefinedVariable, 'r');

What do you think?

Cheers,
Michał Marcin Brzuchalski

[PHP-DEV] Finer control of diagnostics (deprecations, notices, and warnings)

[Rowan Tommins]

Hi all,

Concerns have been raised a few times recently about adding new warnings 
and deprecation notices, particularly:


* That code bases with many instances of a particular pattern see a lot 
of noise when a message is added
* That library maintainers face pressure to fix deprecations from users 
who don't want to see those messages in their logs


I don't think "stop adding new diagnostics to PHP" is a good solution to 
these problems, and have thought of two ideas which might improve 
things; both need refinement, but I hope can at least act as discussion 
starters.



The first idea is directory-level error_reporting configuration.

In principle, this would be very simple: a mechanism (ini setting or 
function) that lets a user specify a different error_reporting level for 
all code compiled from a particular directory. The most common use I 
foresee is reducing reporting in third-party libraries, e.g.


error_reporting=E_ALL
error_reporting[*/vendor/*]=E_ERROR+E_WARNING

This would hopefully reduce pressure on maintainers to fix deprecation 
notices as soon as they appear, because they would no longer be 
cluttering the user's logs.



The second idea is diagnostic codes or categories.

This is more complicated, because it requires classifying all existing 
diagnostics to add extra information, but would allow users to act 
differently on specific messages. They might suppress them, downgrade 
Warnings to Notices, or even upgrade Notices to Warnings - as they might 
with rules in an IDE or Static Analysis tool.


As an extension, the @ operator could be enhanced to suppress a specific 
diagnostic, so that the following would give an "undefined variable" 
warning, but be silent about the file not existing:


@{FILE_NOT_FOUND}fopen($undefinedVariable, 'r');


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Benjamin Eberlei]

On Mon, Nov 15, 2021 at 11:26 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:

> Hi Nikita, hi everybody,
>
> Le mer. 25 août 2021 à 12:03, Nikita Popov  a écrit
> :
>
> > Hi internals,
> >
> > I'd like to propose the deprecation of "dynamic properties", that is
> > properties that have not been declared in the class (stdClass and
> > __get/__set excluded, of course):
> >
> > https://wiki.php.net/rfc/deprecate_dynamic_properties
> >
> > This has been discussed in various forms in the past, e.g. in
> > https://wiki.php.net/rfc/locked-classes as a class modifier and
> > https://wiki.php.net/rfc/namespace_scoped_declares /
> >
> >
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md
> > as a declare directive.
> >
> > This RFC takes the more direct route of deprecating this functionality
> > entirely. I expect that this will have relatively little impact on modern
> > code (e.g. in Symfony I could fix the vast majority of deprecation
> warnings
> > with a three-line diff), but may have a big impact on legacy code that
> > doesn't declare properties at all.
> >
>
> Thanks for the RFC, it makes sense to me and I support the move.
>
> Since Symfony is mentioned in the RFC, I thought you might want to know
> about this PR, that removes dynamic properties from the Symfony codebase:
> https://github.com/symfony/symfony/pull/44037/files
>
> What Nikita describes in the RFC is correct: declaring+unsetting the
> "groups" property works.
> There's just one more thing I had to do; I also had to replace two calls to
> property_exists:
>
> -if (!property_exists($this, 'groups')) {
> +if (!isset(((array) $this)['groups'])) {
>
> The rest are test cases where we've been lazily accepting fixtures with
> undeclared properties. No big deal, and I'm happy the engine might soon
> help us get a bit stricter in this regard.
>
> I read that some think that this PR is not required because static
> analysers (SA) can report when a dynamic property is used. Although that's
> correct, I think it would be detrimental to PHP as a language if SA tools
> (or any tools actually) were a requirement to code in the safe-n-modern
> way. You should not have to install any complex safeguarding tooling
> infrastructure to start coding; both for newcomers, but also for
> no-so-new-comers.
>

Its not so true from my POV that static analysis can avoid having this
deprecation:

1. static analysis does not work for dynamic assignments,

$object = new SomeDataObject();
$row = $pdo->fetch();
foreach ($row as $column => $value) {
$object->$column = $value;
}

arguably this is one of the important use cases this deprecation fixes.

A second example of this is when doing deserialization into an object from
JSON or XML:

$object = new SomeDataObject();
$objectPayload = json_decode($input, true);
foreach ($objectPayload as $prop => $value) {
$object->$prop = $value;
}

This doesn't apply sole to user input where maybe more validation of input
is necessary, but also for mapping config files to an object.

All this kind of generic code cannot be statically analysed, but this
deprecation and removal has the most value in exactly that use-case.


>
> About the discussion related to deprecations. I've yet to see a better
> reporting system than the current one.
> It's true that too many userland error handlers are throwing instead of
> collecting/logging/skipping deprecations.
> But these can be fixed (and many are being fixed these days, which is
> nice!)
>
> Cheers,
> Nicolas
>

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Nikita Popov]

On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans  wrote:

> Dear Internals,
>
> I think it is a mistake to decide on a whim to move over to GitHub
> issues without having evaluated anything else.
>
> GitHub is a proprietary platform, where unlike with the code
> repositories, the interactions and issues are not easy to migrate out of
> again. It is also now owned by MSFT, and although they are making
> friendly noises towards Open Source, I remain largely skeptical (with as
> a hint, the stuff they're pulling with AI code completion).
>
> I understand and share that "bugsnet" has many issues, and I don't
> necessarily object moving to something else.
>
> However, in the last 25+ years we've always hosted this ourselves, and
> this prevented any sort of vendor lock in. I think it is important to
> own our own data here, or at least have full access to any interactions.
>
> This jump to GitHub Issues feels rushed, and I worry that we end up
> making the wrong decision, especially because from the RFC it seems we
> need to build some functionality (tags scheme, for example) on top of
> it. And this will need to be maintained separately, and I worry that too
> few people are going to be interested in gardening the issues on GH.
>
> I believe we would be much better served having a look what is
> available, and see what else is suitable. I'm therefore intending to
> vote no on this.


Hey Derick,

The RFC includes a bit of discussion of alternatives in abstract (
https://wiki.php.net/rfc/github_issues#alternatives) and the key point
(which has also been brought up by other people in the meantime) is that
the choice of GitHub issues is very much not a whim:

For better or worse, GitHub is where nearly all open-source projects are
hosted, which means that pretty much anyone involved in open-source has an
account there and is familiar with the workflows. It is also where PHP
hosts it's repos and where we accept pull requests. An alternative issue
tracker has to compete not just on technical grounds, but also on
integration, familiarity and network-effect. For an open-source project,
these aspects are quite important when it comes to interaction with casual
contributors.

Working at JetBrains, proposing YouTrack instead of GH issues has certainly
crossed my mind -- there is no doubt that at a technical level, it's a much
better bug tracker than GH issues. But that's simply not the right question
to ask. The right question is whether, given our rather simple
requirements, is it sufficiently better to overshadow the other benefits of
GitHub issues for an open-source project? I don't think so. We just need GH
issues to be "good enough" for our purposes, and I think that at this point
it is.

I'll also mention that the discussion about this migration has been going
on for six months, and in that time all I've ever seen are vague mentions
of alternatives, but nobody has provided any in-depth analysis that goes
beyond a simple name drop. I went through the trouble of providing a
detailed evaluation of how the GitHub issues migration will look like,
while the alternatives are still at the state of "Phabricator is a thing"
(ooops, it actually isn't -- it managed to be discontinued while the
discussion was going on!)

Finally, for me an important part of the migration (whether to GH Issues or
something else) is specifically that we don't host it ourselves, because we
have historically always been really bad at that. Of course, letting
someone else host it is incompatible with the desire to fully "own" our
data. I do appreciate the general sentiment here though.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Nicolas Grekas]

Hi Nikita, hi everybody,

Le mer. 25 août 2021 à 12:03, Nikita Popov  a écrit :

> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
> https://wiki.php.net/rfc/deprecate_dynamic_properties
>
> This has been discussed in various forms in the past, e.g. in
> https://wiki.php.net/rfc/locked-classes as a class modifier and
> https://wiki.php.net/rfc/namespace_scoped_declares /
>
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md
> as a declare directive.
>
> This RFC takes the more direct route of deprecating this functionality
> entirely. I expect that this will have relatively little impact on modern
> code (e.g. in Symfony I could fix the vast majority of deprecation warnings
> with a three-line diff), but may have a big impact on legacy code that
> doesn't declare properties at all.
>

Thanks for the RFC, it makes sense to me and I support the move.

Since Symfony is mentioned in the RFC, I thought you might want to know
about this PR, that removes dynamic properties from the Symfony codebase:
https://github.com/symfony/symfony/pull/44037/files

What Nikita describes in the RFC is correct: declaring+unsetting the
"groups" property works.
There's just one more thing I had to do; I also had to replace two calls to
property_exists:

-if (!property_exists($this, 'groups')) {
+if (!isset(((array) $this)['groups'])) {

The rest are test cases where we've been lazily accepting fixtures with
undeclared properties. No big deal, and I'm happy the engine might soon
help us get a bit stricter in this regard.

I read that some think that this PR is not required because static
analysers (SA) can report when a dynamic property is used. Although that's
correct, I think it would be detrimental to PHP as a language if SA tools
(or any tools actually) were a requirement to code in the safe-n-modern
way. You should not have to install any complex safeguarding tooling
infrastructure to start coding; both for newcomers, but also for
no-so-new-comers.

About the discussion related to deprecations. I've yet to see a better
reporting system than the current one.
It's true that too many userland error handlers are throwing instead of
collecting/logging/skipping deprecations.
But these can be fixed (and many are being fixed these days, which is nice!)

Cheers,
Nicolas

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Andreas Leathley]

On 15.11.21 10:47, Derick Rethans wrote:

GitHub is a proprietary platform, where unlike with the code
repositories, the interactions and issues are not easy to migrate out of
again. It is also now owned by MSFT, and although they are making
friendly noises towards Open Source, I remain largely skeptical (with as
a hint, the stuff they're pulling with AI code completion).


All open-source projects I know and use in relation to PHP development
are on Github (like Composer and Symfony, to just name two big ones),
which in my opinion makes Github an ideal platform for the PHP project
itself, as the barrier of entry is lowered.

This also has the advantage that if Github "becomes evil" (or just gets
worse) for whatever reasons, the PHP project will just be one of many
open-source projects which needs to move to a new place. This gives this
solution a safety in numbers and will probably make it easier to move
rather than harder.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Deleu]

On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans  wrote:

>
> and I worry that too
> few people are going to be interested in gardening the issues on GH.
>
> cheers,
> Derick
>
>
> On Tue, 2 Nov 2021, Nikita Popov wrote:
>
> > Hi internals,
> >
> > The migration from bugs.php.net to GitHub issues has already been
> discussed
> > in https://externals.io/message/114300 and has already happened for
> > documentation issues.
> >
> > I'd like to formally propose to use GitHub for PHP implementation issues
> as
> > well: https://wiki.php.net/rfc/github_issues
> >
> > Regards,
> > Nikita
> >
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
If we do move over to GitHub I know that A LOT of young software engineers
already learn how to use it which reduces the entry barrier. In fact, if
it's possible to help triage bugs without C knowledge, I'm willing to be a
candidate to help out since I know the whole "ticketing system" already, so
it's just a matter of learning about tagging the content. Overall, I think
moving to where developers are is a good decision because it becomes more
accessible for a lot of people that may be willing to help.

Self hosting means that 1) the choice of system will be something that the
pool of people experienced in it will be less than GH Issues 2) someone
will have to maintain the hosting infrastructure for it 3) it will be less
accessible. I'm all for using GH Issues.

-- 
Marco Aurélio Deleu

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Hans Henrik Bergan]

if hosting it ourself is a priority, i suggest looking into GitLab’s
Community Edition, which is entirely open source,
and the GNOME project moved from Bugzilla to GitLab CE in 2018,
here's how that worked out, 2 years later:
https://about.gitlab.com/blog/2020/09/08/gnome-follow-up/
(and the TL;DR is that it worked out great for the GNOME project)


On Mon, 15 Nov 2021 at 10:47, Derick Rethans  wrote:

> Dear Internals,
>
> I think it is a mistake to decide on a whim to move over to GitHub
> issues without having evaluated anything else.
>
> GitHub is a proprietary platform, where unlike with the code
> repositories, the interactions and issues are not easy to migrate out of
> again. It is also now owned by MSFT, and although they are making
> friendly noises towards Open Source, I remain largely skeptical (with as
> a hint, the stuff they're pulling with AI code completion).
>
> I understand and share that "bugsnet" has many issues, and I don't
> necessarily object moving to something else.
>
> However, in the last 25+ years we've always hosted this ourselves, and
> this prevented any sort of vendor lock in. I think it is important to
> own our own data here, or at least have full access to any interactions.
>
> This jump to GitHub Issues feels rushed, and I worry that we end up
> making the wrong decision, especially because from the RFC it seems we
> need to build some functionality (tags scheme, for example) on top of
> it. And this will need to be maintained separately, and I worry that too
> few people are going to be interested in gardening the issues on GH.
>
> I believe we would be much better served having a look what is
> available, and see what else is suitable. I'm therefore intending to
> vote no on this.
>
> cheers,
> Derick
>
>
> On Tue, 2 Nov 2021, Nikita Popov wrote:
>
> > Hi internals,
> >
> > The migration from bugs.php.net to GitHub issues has already been
> discussed
> > in https://externals.io/message/114300 and has already happened for
> > documentation issues.
> >
> > I'd like to formally propose to use GitHub for PHP implementation issues
> as
> > well: https://wiki.php.net/rfc/github_issues
> >
> > Regards,
> > Nikita
> >
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Marco Pivetta]

Hey Derick

On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans  wrote:

> Dear Internals,
>
> I think it is a mistake to decide on a whim to move over to GitHub
> issues without having evaluated anything else.
>
> GitHub is a proprietary platform, where unlike with the code
> repositories, the interactions and issues are not easy to migrate out of
> again. It is also now owned by MSFT, and although they are making
> friendly noises towards Open Source, I remain largely skeptical (with as
> a hint, the stuff they're pulling with AI code completion).
>
> I understand and share that "bugsnet" has many issues, and I don't
> necessarily object moving to something else.
>
> However, in the last 25+ years we've always hosted this ourselves, and
> this prevented any sort of vendor lock in. I think it is important to
> own our own data here, or at least have full access to any interactions.
>
> This jump to GitHub Issues feels rushed, and I worry that we end up
> making the wrong decision, especially because from the RFC it seems we
> need to build some functionality (tags scheme, for example) on top of
> it. And this will need to be maintained separately, and I worry that too
> few people are going to be interested in gardening the issues on GH.
>
> I believe we would be much better served having a look what is
> available, and see what else is suitable. I'm therefore intending to
> vote no on this.
>
> cheers,
> Derick
>

Remember that all information on public repos is also available on
http://www.gharchive.org/
If data retention is the problem, mirroring that could be an effective
solution.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Derick Rethans]

Dear Internals,

On Wed, 10 Nov 2021, Nikita Popov wrote:

> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov  wrote:
> 
> > This RFC takes the more direct route of deprecating this 
> > functionality entirely. I expect that this will have relatively 
> > little impact on modern code (e.g. in Symfony I could fix the vast 
> > majority of deprecation warnings with a three-line diff), but may 
> > have a big impact on legacy code that doesn't declare properties at 
> > all.
> >
> 
> I plan to open voting on this RFC soon. Most of the feedback was 
> positive, apart from the initial choice of opt-int mechanism, and that 
> part should be addressed by the switch to the 
> #[AllowDynamicProperties] attribute.

The voting is now open, but I think one thing was not taken into account 
here, the many small changes that push work to maintainers of Open 
Source library and CI related tools.

In the last few years, the release cadence of PHP has increased, which 
is great for new features. It however has not been helpful to introduce 
many small deprecations and BC breaks in every single release.

This invariably is making maintainers of Open Source anxious, and 
frustrated as so much work is need to keep things up to date. I know 
they are *deprecations*, and applications can turn these off, but that's 
not the case for maintainers of libraries. 

Before we introduce many more of this into PHP 8.2, I think it would be 
wise to figure out a way how to:

- improve the langauge with new features
- keep maintenance cost for open source library and CI tools much lower
- come up with a set of guidelines for when it is necessary to introduce 
  BC breaks and deprecations.

I am all for improving the language and making it more feature rich, but 
we have not spend enough time considering the impacts to the full 
ecosystem. 

I have therefore voted "no" on this RFC, and I hope you will too.

cheers,
Derick

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Migrating to GitHub issues

[Derick Rethans]

Dear Internals,

I think it is a mistake to decide on a whim to move over to GitHub 
issues without having evaluated anything else.

GitHub is a proprietary platform, where unlike with the code 
repositories, the interactions and issues are not easy to migrate out of 
again. It is also now owned by MSFT, and although they are making 
friendly noises towards Open Source, I remain largely skeptical (with as 
a hint, the stuff they're pulling with AI code completion).

I understand and share that "bugsnet" has many issues, and I don't 
necessarily object moving to something else.

However, in the last 25+ years we've always hosted this ourselves, and 
this prevented any sort of vendor lock in. I think it is important to 
own our own data here, or at least have full access to any interactions.

This jump to GitHub Issues feels rushed, and I worry that we end up 
making the wrong decision, especially because from the RFC it seems we 
need to build some functionality (tags scheme, for example) on top of 
it. And this will need to be maintained separately, and I worry that too 
few people are going to be interested in gardening the issues on GH.

I believe we would be much better served having a look what is 
available, and see what else is suitable. I'm therefore intending to 
vote no on this.

cheers,
Derick


On Tue, 2 Nov 2021, Nikita Popov wrote:

> Hi internals,
> 
> The migration from bugs.php.net to GitHub issues has already been discussed
> in https://externals.io/message/114300 and has already happened for
> documentation issues.
> 
> I'd like to formally propose to use GitHub for PHP implementation issues as
> well: https://wiki.php.net/rfc/github_issues
> 
> Regards,
> Nikita
> 

-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php