[RFC] Deprecate dynamic properties

  115800
August 25, 2021 10:02 nikita.ppv@gmail.com (Nikita Popov)
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/0000-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
  115801
August 25, 2021 10:14 kjarli@gmail.com (Lynn)
On Wed, Aug 25, 2021 at 12:03 PM Nikita Popov ppv@gmail.com> 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. >
The project I maintain is massive and it's full of code that implicitly defines properties. As long as the deprecations are clear, I'm 100% behind this proposal as it will finally give me leverage to fix the code base at some point in time.
  115802
August 25, 2021 10:45 rowan.collins@gmail.com (Rowan Tommins)
On 25/08/2021 11:02, Nikita Popov wrote:
> 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 is a bold move, and in principle seems sensible, although I'm slightly scared how many places will need fixing in legacy code bases. I have a couple of concerns with using stdClass as the opt-in mechanism: * The name of that class already leads to a lot of confusion about its purpose - it's not actually "standard" in any way, and new users seeing it as a base class are even more likely to mistake it as some kind of "universal ancestor". Would it be feasible to introduce an alias like "DynamicObject" which more clearly defines its role? * Adding a parent to an existing class isn't always possible, if it already inherits from something else. Perhaps the behaviour could also be available as a trait, which defined stub __get and __set methods, allowing for the replacement of the internal implementation as you've described? Regards, -- Rowan Tommins [IMSoP]
  115804
August 25, 2021 10:52 flaviohbatista@gmail.com (=?UTF-8?Q?Fl=C3=A1vio_Heleno?=)
On Wed, Aug 25, 2021 at 7:46 AM Rowan Tommins collins@gmail.com>
wrote:

> On 25/08/2021 11:02, Nikita Popov wrote: > > 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 is a bold move, and in principle seems sensible, although I'm > slightly scared how many places will need fixing in legacy code bases. > > I have a couple of concerns with using stdClass as the opt-in mechanism: > > * The name of that class already leads to a lot of confusion about its > purpose - it's not actually "standard" in any way, and new users seeing > it as a base class are even more likely to mistake it as some kind of > "universal ancestor". Would it be feasible to introduce an alias like > "DynamicObject" which more clearly defines its role? > > * Adding a parent to an existing class isn't always possible, if it > already inherits from something else. Perhaps the behaviour could also > be available as a trait, which defined stub __get and __set methods, > allowing for the replacement of the internal implementation as you've > described? > > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Although not having voting karma, I'm +1 on this.
I've always preferred explicit over implicit code as it makes the learning path to newcomers a lot easier to grasp. When we talk about legacy code, more frequently than not is that legacy code is unlikely to run on the latest version of PHP, thus I'm not entirely sure if that's a super strong argument against it, but I may be missing something. -- Atenciosamente, Flávio Heleno
  115806
August 25, 2021 11:05 office.hamzaahmad@gmail.com (Hamza Ahmad)
HI Nikita,

What if you consider this instead? Rather allowing STD class as an
exception to dynamic properties, why not introduce STDAbstract?
```php
interface STDClassInterface
{
public function __get(string $name) : mixed;
public function __set(string $name, mixed $value = null) : mixed;
/* * other magic methods */
};
abstract class STDClassAbstract implements STDClassInterface {/* *
interface methods */}
Class STDClass extends SDTClassAbstract{}
``

Best
Hamza

On 8/25/21, Rowan Tommins collins@gmail.com> wrote:
> On 25/08/2021 11:02, Nikita Popov wrote: >> 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 is a bold move, and in principle seems sensible, although I'm > slightly scared how many places will need fixing in legacy code bases. > > I have a couple of concerns with using stdClass as the opt-in mechanism: > > * The name of that class already leads to a lot of confusion about its > purpose - it's not actually "standard" in any way, and new users seeing > it as a base class are even more likely to mistake it as some kind of > "universal ancestor". Would it be feasible to introduce an alias like > "DynamicObject" which more clearly defines its role? > > * Adding a parent to an existing class isn't always possible, if it > already inherits from something else. Perhaps the behaviour could also > be available as a trait, which defined stub __get and __set methods, > allowing for the replacement of the internal implementation as you've > described? > > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
  115809
August 25, 2021 12:35 a.leathley@gmx.net (Andreas Leathley)
On 25.08.21 12:45, Rowan Tommins wrote:
> * Adding a parent to an existing class isn't always possible, if it > already inherits from something else. Perhaps the behaviour could also > be available as a trait, which defined stub __get and __set methods, > allowing for the replacement of the internal implementation as you've > described? > Couldn't this be easily done in userland with the ArrayLikeObject (an
example in the RFC) or something similar, just done as a trait? Maybe having an example trait implementation that basically "imitates" stdClass in terms of dynamic properties would be helpful to show in the RFC, to highlight a possible resolution path for legacy code with this problem. This could be an example implementation: trait DynamicPropertiesTrait {     private array $dynamicProperties = [];     public function &__get(string $name): mixed { return $this->dynamicProperties[$name]; }     public function __isset(string $name): bool { return isset($this->dynamicProperties[$name]); }     public function __set(string $name, mixed $value): void { $this->dynamicProperties[$name] = $value; }     public function __unset(string $name): void { unset($this->dynamicProperties[$name]); } }
  115810
August 25, 2021 12:45 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Aug 25, 2021 at 12:45 PM Rowan Tommins collins@gmail.com>
wrote:

> On 25/08/2021 11:02, Nikita Popov wrote: > > 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 is a bold move, and in principle seems sensible, although I'm > slightly scared how many places will need fixing in legacy code bases. > > I have a couple of concerns with using stdClass as the opt-in mechanism: > > * The name of that class already leads to a lot of confusion about its > purpose - it's not actually "standard" in any way, and new users seeing > it as a base class are even more likely to mistake it as some kind of > "universal ancestor". Would it be feasible to introduce an alias like > "DynamicObject" which more clearly defines its role? > > * Adding a parent to an existing class isn't always possible, if it > already inherits from something else. Perhaps the behaviour could also > be available as a trait, which defined stub __get and __set methods, > allowing for the replacement of the internal implementation as you've > described? >
So, a few thoughts: First of all, I should say that "extends stdClass" is not so much an explicit escape hatch I built into this, it's more something that arises naturally: We obviously need to keep support for dynamic properties on stdClass, and if we do so, I would expect that to apply to subclasses as well. As such, I believe that the "extends stdClass" escape hatch is something that's going to work anyway -- the only question would be whether we want to provide additional opt-ins in the form of interfaces/traits/attributes/etc. Second, I consider "extends stdClass" to be something of a last-ditch option. If you encounter a dynamic property deprecation warning, you should generally resolve it in some other way, and only fall back to "extends stdClass" as the final option. All that said, yes, we could add a trait. It would basically be ArrayLikeObject from the RFC with "class" replaced by "trait". However, I'm not sure this is really worthwhile. The nice thing about extending stdClass is that it a) gives you much more efficient property access than __get/__set and b) matches current behavior. Implementing such a trait, even if bundled, doesn't really give you any advantages over implemening __get/__set yourself. It would not make use of an optimized implementation (or at least, the implementation would still be calling real __get/__set methods) and the behavior would be limited to what the trait provides. A custom implementation is not significantly harder (the minimal implementation is five lines of code) but gives you more control, e.g. you might want just the minimal implementation, or you might want to also support Traversable, have a custom __debugInfo(), etc. My preliminary position would be that if a) you can't avoid dynamic properties in any other way and b) you can't extend stdClass either, then you should go with c) implementing __get/__set yourself, as appropriate for the given use-case. Regards, Nikita
  115811
August 25, 2021 13:51 rowan.collins@gmail.com (Rowan Tommins)
On 25/08/2021 13:45, Nikita Popov wrote:

> We obviously need to keep support for dynamic properties on stdClass, > and if we do so, I would expect that to apply to subclasses as well.
Does that actually follow, though? Right now, there is no advantage to extending stdClass, so no reason to expect existing code to do so, and no reason for people doing so to expect it to affect behaviour.
> Second, I consider "extends stdClass" to be something of a last-ditch > option. If you encounter a dynamic property deprecation warning, you > should generally resolve it in some other way, and only fall back to > "extends stdClass" as the final option.
That's a reasonable argument in terms of the multiple inheritance case. My concern about the name remains though: people already do get confused by the name "stdClass", because it's not in any way "standard", and tells you nothing about what it does. Reading "class Foo extends stdClass" gives the reader no clues what magic behaviour is being inherited; "class Foo extends DynamicObject" would be much more clear. Similarly, "$foo = new DynamicObject; $foo->bar = 42;" is clearer than "$foo = new stdClass; $foo->bar = 42;" Regards, -- Rowan Tommins [IMSoP]
  115812
August 25, 2021 14:00 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Aug 25, 2021 at 3:51 PM Rowan Tommins collins@gmail.com>
wrote:

> On 25/08/2021 13:45, Nikita Popov wrote: > > > We obviously need to keep support for dynamic properties on stdClass, > > and if we do so, I would expect that to apply to subclasses as well. > > Does that actually follow, though? Right now, there is no advantage to > extending stdClass, so no reason to expect existing code to do so, and > no reason for people doing so to expect it to affect behaviour. >
Isn't this a direct consequence of LSP? We can't just drop behavior when extending. Only way for this not to follow would be if we disallowed extending from stdClass entirely, which we presumably don't want to do.
> Second, I consider "extends stdClass" to be something of a last-ditch > > option. If you encounter a dynamic property deprecation warning, you > > should generally resolve it in some other way, and only fall back to > > "extends stdClass" as the final option. > > > That's a reasonable argument in terms of the multiple inheritance case. > > My concern about the name remains though: people already do get confused > by the name "stdClass", because it's not in any way "standard", and > tells you nothing about what it does. > > Reading "class Foo extends stdClass" gives the reader no clues what > magic behaviour is being inherited; "class Foo extends DynamicObject" > would be much more clear. Similarly, "$foo = new DynamicObject; > $foo->bar = 42;" is clearer than "$foo = new stdClass; $foo->bar = 42;" >
Yes, I can see the argument for aliasing stdClass to something more meaningful, even independently of this RFC. I'm not sure it will have a big impact for this use-case though, because using the new name would require polyfilling it, so I'd expect people would stick to the old name in the foreseeable future... Regards, Nikita
  115818
August 25, 2021 14:49 rowan.collins@gmail.com (Rowan Tommins)
On 25/08/2021 15:00, Nikita Popov wrote:
> I'm not sure it will have a big impact for this use-case though, > because using the new name would require polyfilling it, so I'd expect > people would stick to the old name in the foreseeable future...
Not necessarily - it depends what versions you need to support, and what your migration strategy is. Since it's just a deprecation notice initially, you could support 8.1 and 8.2 on the same code base with no changes at all - that's what deprecation notices are for, to give a lead time before changes are mandatory. Once the code base no longer needed to support 8.1, "extends DynamicObject" could be added. For many code bases, that will be long before the feature is actually removed - for a private project, maybe as soon as it's on 8.2 in production. Regards, -- Rowan Tommins [IMSoP]
  115813
August 25, 2021 14:04 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins collins@gmail.com>
wrote:

> On 25/08/2021 13:45, Nikita Popov wrote: > > > We obviously need to keep support for dynamic properties on stdClass, > > and if we do so, I would expect that to apply to subclasses as well. > > Does that actually follow, though? Right now, there is no advantage to > extending stdClass, so no reason to expect existing code to do so, and > no reason for people doing so to expect it to affect behaviour. > > > > Second, I consider "extends stdClass" to be something of a last-ditch > > option. If you encounter a dynamic property deprecation warning, you > > should generally resolve it in some other way, and only fall back to > > "extends stdClass" as the final option. > > > That's a reasonable argument in terms of the multiple inheritance case. > > My concern about the name remains though: people already do get confused > by the name "stdClass", because it's not in any way "standard", and > tells you nothing about what it does. > > Reading "class Foo extends stdClass" gives the reader no clues what > magic behaviour is being inherited; "class Foo extends DynamicObject" > would be much more clear. Similarly, "$foo = new DynamicObject; > $foo->bar = 42;" is clearer than "$foo = new stdClass; $foo->bar = 42;" > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Please don't do this. Call it bad coding practices or not, but this was
something I've considered a feature of PHP and have actually built things around it. It's not something that can be easily refactored since it was part of the design. -- Chase Peeler chasepeeler@gmail.com
  115836
August 25, 2021 20:56 ramsey@php.net (Ben Ramsey)
--9T0kEoBqncr6QLdj4opjFb23AIhnDfYXp
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Chase Peeler wrote on 8/25/21 09:04:
> Please don't do this. Call it bad coding practices or not, but this was=
> something I've considered a feature of PHP and have actually built thin= gs
> around it. It's not something that can be easily refactored since it wa= s
> part of the design.
Since the stdClass behavior is retained in this proposal, could you change your base classes to `extend stdClass`? Cheers, Ben --9T0kEoBqncr6QLdj4opjFb23AIhnDfYXp--
  115840
August 25, 2021 22:37 mike@newclarity.net (Mike Schinkel)
> On Aug 25, 2021, at 10:04 AM, Chase Peeler <chasepeeler@gmail.com> wrote: > > On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins collins@gmail.com> > wrote: > >> On 25/08/2021 13:45, Nikita Popov wrote: >> >>> We obviously need to keep support for dynamic properties on stdClass, >>> and if we do so, I would expect that to apply to subclasses as well. >> >> Does that actually follow, though? Right now, there is no advantage to >> extending stdClass, so no reason to expect existing code to do so, and >> no reason for people doing so to expect it to affect behaviour. >> >> >>> Second, I consider "extends stdClass" to be something of a last-ditch >>> option. If you encounter a dynamic property deprecation warning, you >>> should generally resolve it in some other way, and only fall back to >>> "extends stdClass" as the final option. >> >> >> That's a reasonable argument in terms of the multiple inheritance case. >> >> My concern about the name remains though: people already do get confused >> by the name "stdClass", because it's not in any way "standard", and >> tells you nothing about what it does. >> >> Reading "class Foo extends stdClass" gives the reader no clues what >> magic behaviour is being inherited; "class Foo extends DynamicObject" >> would be much more clear. Similarly, "$foo = new DynamicObject; >> $foo->bar = 42;" is clearer than "$foo = new stdClass; $foo->bar = 42;" >> >> Regards, >> >> -- >> Rowan Tommins >> [IMSoP] >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >> > Please don't do this. Call it bad coding practices or not, but this was > something I've considered a feature of PHP and have actually built things > around it. It's not something that can be easily refactored since it was > part of the design.
While I tend to really object to BC breakage, when I saw this proposal I was all for it because it disallows a practice that I have seen used all too often in cases where there was no good reason to not declare the properties, and I know that to be fact because the cases I am referring to are ones where I refactored to use declared properties. That said, I'd be really interested in seeing use-cases where having dynamic properties is essential to an architecture and where it could not be easily refactored. I cannot envision any, but I am sure that I am just limited by the extent of my vision and so would like to know what those use-cases would be. --------- Speaking of, it would seem like if dynamic properties were to be deprecated PHP should also add a function that would allow registering a callable as global hook to be called every time ANY object has a property dynamically accessed or assigned — conceptually like how spl_autoload_register() works — so that developers could run their programs to see what properties are used. The hook could collect class names, property names and data types to help developers who need to update their code discover the information required for their class declarations. Because doing it manually is a real PITA. As would be adding __get()/__set() to every class when you have lots of classes and you'd need to delete all that code later anyway. -Mike
  115814
August 25, 2021 14:08 pierre-php@processus.org (Pierre)
Le 25/08/2021 à 15:51, Rowan Tommins a écrit :
> On 25/08/2021 13:45, Nikita Popov wrote: > >> We obviously need to keep support for dynamic properties on stdClass, >> and if we do so, I would expect that to apply to subclasses as well. > > Does that actually follow, though? Right now, there is no advantage to > extending stdClass, so no reason to expect existing code to do so, and > no reason for people doing so to expect it to affect behaviour. > > >> Second, I consider "extends stdClass" to be something of a last-ditch >> option. If you encounter a dynamic property deprecation warning, you >> should generally resolve it in some other way, and only fall back to >> "extends stdClass" as the final option. > > > That's a reasonable argument in terms of the multiple inheritance case. > > My concern about the name remains though: people already do get > confused by the name "stdClass", because it's not in any way > "standard", and tells you nothing about what it does. > > Reading "class Foo extends stdClass" gives the reader no clues what > magic behaviour is being inherited; "class Foo extends DynamicObject" > would be much more clear. Similarly, "$foo = new DynamicObject; > $foo->bar = 42;" is clearer than "$foo = new stdClass; $foo->bar = 42;" > > Regards, > Hello,
And why not adding an extra keyword, such as: ``` ``` Regards, -- Pierre
  115815
August 25, 2021 14:18 internals@lists.php.net ("Levi Morrison via internals")
> And why not adding an extra keyword, such as: > > ``` > dynamic class Foo { } // Dynamic allowed > class Bar {} // Dynamic disallowed > ?> > ```
I am opposed. IMO it's not worth adding anything to the language to preserve this existing behavior other than allowing `__get`/`__set`, etc, which already exist for this purpose. Additionally, there are technical benefits to removing dynamic properties altogether, so I don't think we should "half" remove it. See https://wiki.php.net/rfc/deprecate_dynamic_properties#internal_impact.
  115803
August 25, 2021 10:52 denis@mobilejoomla.com (Denis Ryabov)
On 25.08.2021 13:02, 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/0000-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
I use dynamical properties in a legacy code for lazy object creation in the dependency container (with properties declared using @property phpDoc comment, so that PhpStorm IDE supports them). But in my case it's not a problem to refactor that code. I'd suggest to consider "use stdClassTrait" (the name is just for example) as an alternative to "extends stdClass" and "implements stdClassInterface", because 1) It allows to further implement __get/__set in that trait, and 2) It's possible to don't require base abstract class to extend stdClass when dynamical properties are used in a child class only.
  115805
August 25, 2021 10:55 ocramius@gmail.com (Marco Pivetta)
Hey Nikita

On Wed, Aug 25, 2021 at 12:03 PM Nikita Popov ppv@gmail.com> 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/0000-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. >
I'm totally on board with this! Others in the thread have mentioned that these dynamic properties can be used for lazy-loading purposes, but I think we've demonstrated (over the years) that this can be achieved in a type-safe way anyway, and dynamic properties are not needed at all. Over the past decade, I've not seen a single valid use of dynamic properties either. If this passes, I'll also deprecate and discontinue experiments like https://github.com/Ocramius/LazyProperty Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  115807
August 25, 2021 11:28 ayesh@php.watch (Ayesh Karunaratne)
> > 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/0000-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
Hi Nikita, Thanks for opening this, I'm very supportive of this. Having some Drupal and other legacy background, I'm afraid this could disrupt a lot of Drupal applications, which uses dynamic properties quite extensively in its Entity APIs, Views, etc. I totally agree that it is a bad practice, but that's what half a million or so Drupal 7 web sites do. Perhaps, we can make it an easy to opt-in with a keyword (`locked class Foo {}`) or an interface (`Foo implements LockedClass {}`), or provide an easy opt-out (similar to the tentative return type attribute)? Thank you, Ayesh.
  115808
August 25, 2021 11:29 internals@lists.php.net ("Björn Larsson via internals")
Den 2021-08-25 kl. 12:02, skrev Nikita Popov:
> 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/0000-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 > I'm in favour of the proposal as long as the stdClass is leaved as is!
For declared classes I think it's a good idea. We have legacy code that is littered with dynamic properties using stdClass. It runs today on PHP 7.4.22 and we plan to migrate to PHP 8 as soon as some Open source libraries works under PHP 8. Being forced to rewrite this if this proposal changes to also disallow stdClass dynamic properties would have zero benefits for the app itself and only incur a cost. Regards //Björn L
  115816
August 25, 2021 14:26 tysonandre775@hotmail.com (tyson andre)
Hi Nikita Popov,

> 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/0000-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.
I'd had some concerns. It might be too soon after your addition of WeakMap. https://www.php.net/weakmap was introduced in PHP 8.0 (and WeakReference in 7.4), so applications/libraries fixing the deprecation may need to drop support for php 7.x early. Applications attempting to polyfill a WeakMap in earlier PHP versions would potentially leak a lot of memory in php 7.x. - I don't know how many minor versions to expect before 9.0 is out - Is it feasible for a developer to create a native PECL polyfill for WeakMap for earlier PHP versions that has a subset of the functionality the native weak reference counting does? (e.g. to only free polyfilled weak references when cyclic garbage collection is triggered and the reference count is 1). Additionally, it makes it less efficient (but still feasible) to associate additional fields with libraries or native classes/PECLs you don't own (especially for circular data structures), especially if they need to be serialized later. (it isn't possible to serialize WeakMap, and the WeakMap would have fields unrelated to the data being serialized) I guess you can have a wrapper class that iterates over a WeakMap to capture and serialize the values that still exist in SplObjectStorage, though. (Though other languages do just fine without this functionality) I'm not sure if a library owner would want to change their class hierarchy to extend stdClass (to avoid changing the behavior of anything using `$x instanceof stdClass`) and the attribute/trait approach might be more acceptable to library owners. E.g. https://github.com/vimeo/psalm/blob/master/src/Psalm/Internal/Analyzer/Statements/Expression/Call/FunctionCallAnalyzer.php would set a dynamic property `$stmt->pure` in `PhpParser\Node\Expr\FuncCall $stmt` in a vendor dependency on php-parser. Regards, Tyson
  115817
August 25, 2021 14:49 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Aug 25, 2021 at 4:26 PM tyson andre <tysonandre775@hotmail.com>
wrote:

> Hi Nikita Popov, > > > 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/0000-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. > > I'd had some concerns. > > It might be too soon after your addition of WeakMap. > https://www.php.net/weakmap was introduced in PHP 8.0 (and WeakReference > in 7.4), > so applications/libraries fixing the deprecation may need to drop support > for php 7.x early. > Applications attempting to polyfill a WeakMap in earlier PHP versions > would potentially leak a lot of memory in php 7.x. > > - I don't know how many minor versions to expect before 9.0 is out > - Is it feasible for a developer to create a native PECL polyfill for > WeakMap for earlier PHP versions that has a > subset of the functionality the native weak reference counting does? > (e.g. to only free polyfilled weak references when cyclic garbage > collection is triggered and the reference count is 1). >
For compatibility with < PHP 7.4 in this use case I'd suggest to either suppress the deprecation for a particular assignment, or to pick the used mechanism depending on PHP version. We don't have an official schedule for major versions, but going by the last few releases, I'd guess that it happens after PHP 8.4, or around that time :) I think an approximate PECL polyfill (that tries to free on GC) would be possible, but I'm not sure it would really be useful relative to having version-dependent behavior.
> Additionally, it makes it less efficient (but still feasible) to associate > additional fields > with libraries or native classes/PECLs you don't own (especially for > circular data structures), especially if they need to be serialized later. >
Efficiency probably depends on the case here -- while I'd expect the dynamic property to be more efficient on access than the WeakMap, it will likely also use more memory, sometimes much more.
> (it isn't possible to serialize WeakMap, and the WeakMap would have fields > unrelated to the data being serialized) > I guess you can have a wrapper class that iterates over a WeakMap to > capture and serialize the values that still exist in SplObjectStorage, > though. > (Though other languages do just fine without this functionality) >
Right, the WeakMap approach will not impact the serialization of the object, as well as other property based behaviors, such as comparison semantics. I would usually count that as an advantage (what you do shouldn't impact the behavior of 3rd-party classes), but there's probably use cases for everything :)
> I'm not sure if a library owner would want to change their class hierarchy > to extend stdClass (to avoid changing the behavior of anything using `$x > instanceof stdClass`) and the attribute/trait approach might be more > acceptable to library owners. > E.g. > https://github.com/vimeo/psalm/blob/master/src/Psalm/Internal/Analyzer/Statements/Expression/Call/FunctionCallAnalyzer.php > would set a dynamic property `$stmt->pure` in > `PhpParser\Node\Expr\FuncCall $stmt` in a vendor dependency on php-parser. >
I wouldn't want library authors to change their class hierarchy for 3rd-party use cases, unless those use cases are actually fundamental to the library in some way. For PHP-Parser this is actually the case, which is why it offers the Node::setAttribute() API. The intended way to do this would be $stmt->setAttribute('pure', true) in this case. Regards, Nikita
  115819
August 25, 2021 15:28 pollita@php.net (Sara Golemon)
On Wed, Aug 25, 2021 at 5:03 AM Nikita Popov ppv@gmail.com> wrote:
> 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 RFC offers `extends stdClass` as a way to opt-in to the use of dynamic properties.
> This makes the assumption that existing uses of dynamic properties are all
root classes. I don't think that assumption can be made.
> Some people have suggested that we could use a magic marker > interface (implements SupportsDynamicProperties), > an attribute (#[SupportsDynamicProperties]) > or a trait (use DynamicProperties;) instead. > My gut-check says an Attribute works well enough. This will unlock the
class (disable deprecation warning) in 8.2+ and be ignored in earlier releases (8.0 and 8.1 would need an auto-loaded polyfill userspace attribute obviously, but that's a tractable problem). #[SupportsDynamicProperties] class Foo { ... }
> The Locked classes RFC took an alternative approach to this problem space: > Rather than deprecating/removing dynamic properties and providing an opt-in
> for specific classes, it instead allowed marking specific classes as locked in
> order to forbid creation of dynamic properties on them. > > I don't believe that this is the right strategy, because in contemporary code,
> classes being “locked” is the default state, while classes that require dynamic
> properties are a rare exception. Additionally, this requires that class owners
> (which may be 3rd party packages) consistently add the “locked” keyword > to be effective. > I struggle here, because the opt-in approach is the most BC, but I actually
think you're right. I think[citation needed] that dynamic props are probably rare enough that as long as the escape hatch is clear, we can be a little more bold about nudging the ecosystem forward. I will counter however, that the same issue with 3rd party libraries applies to opt-out as opt-in. A third party library that's undermaintained (and uses dynamic props) won't be able to be used out of the box once we apply this. I don't think that's enough to scare us off, it just means that the opt-in side of that argument cancels out. -Sara
  115820
August 25, 2021 16:05 larry@garfieldtech.com ("Larry Garfield")
On Wed, Aug 25, 2021, at 10:28 AM, Sara Golemon wrote:
> On Wed, Aug 25, 2021 at 5:03 AM Nikita Popov ppv@gmail.com> wrote: > > 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 RFC offers `extends stdClass` as a way to opt-in to the use of > dynamic properties. > > > This makes the assumption that existing uses of dynamic properties are all > root classes. I don't think that assumption can be made. > > > Some people have suggested that we could use a magic marker > > interface (implements SupportsDynamicProperties), > > an attribute (#[SupportsDynamicProperties]) > > or a trait (use DynamicProperties;) instead. > > > My gut-check says an Attribute works well enough. This will unlock the > class (disable deprecation warning) in 8.2+ and be ignored in earlier > releases (8.0 and 8.1 would need an auto-loaded polyfill userspace > attribute obviously, but that's a tractable problem). > > #[SupportsDynamicProperties] > class Foo { ... } > > > The Locked classes RFC took an alternative approach to this problem space: > > Rather than deprecating/removing dynamic properties and providing an > opt-in > > for specific classes, it instead allowed marking specific classes as > locked in > > order to forbid creation of dynamic properties on them. > > > > I don't believe that this is the right strategy, because in contemporary > code, > > classes being “locked” is the default state, while classes that require > dynamic > > properties are a rare exception. Additionally, this requires that class > owners > > (which may be 3rd party packages) consistently add the “locked” keyword > > to be effective. > > > I struggle here, because the opt-in approach is the most BC, but I actually > think you're right. I think[citation needed] that dynamic props are > probably rare enough that as long as the escape hatch is clear, we can be a > little more bold about nudging the ecosystem forward. I will counter > however, that the same issue with 3rd party libraries applies to opt-out as > opt-in. A third party library that's undermaintained (and uses dynamic > props) won't be able to be used out of the box once we apply this. I don't > think that's enough to scare us off, it just means that the opt-in side of > that argument cancels out. > > -Sara
I am overall in favor of this move and making declared-only the default. What I'm still undecided on is what escape hatch should be allowed. I agree that "you can extend stdClass already" isn't a good one, because that isn't viable in many cases. The most viable options in my mind are "use __get/__set yourself, you heathen" and an attribute. The benefit of an attribute over an interface or new parent class is that it's silently backward compatible, especially since attributes are comments in <8.0 versions, so legacy code can add that marker and still be compatible with anything from 5.0 on. The "internal impact" section makes me lean toward the "__get/__set" option, but I don't fully understand the benefits of the impact. It seems it would make the engine a little tidier and more efficient, but I don't have a good sense for how much more efficient, which would need to be balanced against how much more INefficient user-space code with dynamic properties would become. (Either using __get/__set itself, or inheriting from a future stdClass that implements them internally.) IMO we should prioritize engine efficiency over edge-case efficiency (which dynamic properties are these days), but the amount still matters. I'm currently working on some improvements to the FIG to allow it to release small, incomplete code libraries or shared type libraries. Perhaps a fully user-space BC trait with the basic behavior (basically what's shown in the RFC) could live there? (Not speaking on FIG's behalf, here, just musing aloud.) --Larry Garfield
  115837
August 25, 2021 21:02 ramsey@php.net (Ben Ramsey)
--oGolVVusa5BmXiFJpZwc3PyaAUAQb3TQ5
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Sara Golemon wrote on 8/25/21 10:28:
> My gut-check says an Attribute works well enough. This will unlock the=
> class (disable deprecation warning) in 8.2+ and be ignored in earlier > releases (8.0 and 8.1 would need an auto-loaded polyfill userspace > attribute obviously, but that's a tractable problem). >=20 > #[SupportsDynamicProperties] > class Foo { ... }
I like this approach.
> I struggle here, because the opt-in approach is the most BC, but I actu= ally
> think you're right. I think[citation needed] that dynamic props are > probably rare enough that as long as the escape hatch is clear, we can = be a
> little more bold about nudging the ecosystem forward. I'd feel better about this if we had that citation. In modern code, I
agree they are probably rare, but I think there's a lot of legacy code that makes heavy use of dynamic properties as an important feature of PHP. (I'm working on one such project right now.) Cheers, Ben --oGolVVusa5BmXiFJpZwc3PyaAUAQb3TQ5--
  115848
August 26, 2021 08:34 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Aug 25, 2021 at 5:28 PM Sara Golemon <pollita@php.net> wrote:

> On Wed, Aug 25, 2021 at 5:03 AM Nikita Popov ppv@gmail.com> wrote: > > 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 RFC offers `extends stdClass` as a way to opt-in to the use of > dynamic properties. > > > This makes the assumption that existing uses of dynamic properties are all > root classes. I don't think that assumption can be made. > > > Some people have suggested that we could use a magic marker > > interface (implements SupportsDynamicProperties), > > an attribute (#[SupportsDynamicProperties]) > > or a trait (use DynamicProperties;) instead. > > > My gut-check says an Attribute works well enough. This will unlock the > class (disable deprecation warning) in 8.2+ and be ignored in earlier > releases (8.0 and 8.1 would need an auto-loaded polyfill userspace > attribute obviously, but that's a tractable problem). > > #[SupportsDynamicProperties] > class Foo { ... } >
The crux of the issue is what our end goal is: 1. Require users to explicitly annotate classes that use dynamic properties, but otherwise keep dynamic properties as a fully supported part of the core language. 2. Remove support for dynamic properties entirely. The core language only has declared properties and __get/__set, and nothing else. stdClass is just a very efficient implementation of __get/__set. The RFC is currently written under the assumption that the end goal is (2). To support that, I believe that "extends stdClass" and "use DynamicProperties" are the only viable approaches. The former, because it inherits stdClass behavior, the latter because it's literally __get/__set. An attribute would require retaining the capability to have arbitrary classes with dynamic properties. Now, if the actual goal is (1) instead, then I fully agree that using a #[SupportsDynamicProperties] attribute is the ideal solution. It can be easily applied anywhere and has no BC concerns. Heck, someone who just doesn't care could easily slap it on their whole codebase without spending brain cycles on more appropriate solutions. I do think that just (1) by itself would already be very worthwhile. If that's all we can reasonably target, then I'd be fine with the #[SupportsDynamicProperties] solution. Though if (2) is viable without too many complications, then I think that would be the better final state to reach.
> > The Locked classes RFC took an alternative approach to this problem > space: > > Rather than deprecating/removing dynamic properties and providing an > opt-in > > for specific classes, it instead allowed marking specific classes as > locked in > > order to forbid creation of dynamic properties on them. > > > > I don't believe that this is the right strategy, because in contemporary > code, > > classes being “locked” is the default state, while classes that require > dynamic > > properties are a rare exception. Additionally, this requires that class > owners > > (which may be 3rd party packages) consistently add the “locked” keyword > > to be effective. > > > I struggle here, because the opt-in approach is the most BC, but I > actually think you're right. I think[citation needed] that dynamic props > are probably rare enough that as long as the escape hatch is clear, we can > be a little more bold about nudging the ecosystem forward. I will counter > however, that the same issue with 3rd party libraries applies to opt-out as > opt-in. A third party library that's undermaintained (and uses dynamic > props) won't be able to be used out of the box once we apply this. I don't > think that's enough to scare us off, it just means that the opt-in side of > that argument cancels out. >
I think the argument isn't quite symmetric: A 3rd-party library in maintenance-only mode has essentially no incentive to go out of their way and add a "locked" keyword/attribute to their classes. Adding some missing property declarations to keep working on new PHP versions is a different matter. Regards, Nikita
  115871
August 26, 2021 22:10 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> The crux of the issue is what our end goal is: > > 1. Require users to explicitly annotate classes that use dynamic > properties, but otherwise keep dynamic properties as a fully supported part > of the core language. > 2. Remove support for dynamic properties entirely. The core language only > has declared properties and __get/__set, and nothing else. stdClass is just > a very efficient implementation of __get/__set.
I think goal (1) is reasonable for the long run, and goal (2) is taking it a bit too far for PHP. -- Stas Malyshev smalyshev@gmail.com
  115874
August 27, 2021 03:02 pierre.php@gmail.com (Pierre Joye)
Hi Stan,

On Fri, Aug 27, 2021 at 5:10 AM Stanislav Malyshev <smalyshev@gmail.com> wrote:
> > Hi! > > > The crux of the issue is what our end goal is: > > > > 1. Require users to explicitly annotate classes that use dynamic > > properties, but otherwise keep dynamic properties as a fully supported part > > of the core language. > > 2. Remove support for dynamic properties entirely. The core language only > > has declared properties and __get/__set, and nothing else. stdClass is just > > a very efficient implementation of __get/__set. > > I think goal (1) is reasonable for the long run, and goal (2) is taking > it a bit too far for PHP.
I feel the same way. However my gut feeling tells me that we will end up with (2) sooner or later. Having StdClass behaving differently (even if it is technically not, I don't think the "it is a more efficient get/set implementation" will make it through our users base) looks inconsistent. I don't know how others feel about it, I think most want to go the path to (2) and a more strict, if not almost fully strict PHP. Core devs to simplify the engine, users to allow them easier checks and safety in their frameworks or libs. End user don't really bother as far as I can see. We may have to decide once the long term vision for PHP and then do the changes accordingly, and more importantly, with consistency. Best, -- Pierre @pierrejoye | http://www.libgd.org
  115875
August 27, 2021 03:56 tobias.nyholm@gmail.com (Tobias Nyholm)
Just giving my 2 cents: 

> 2. Remove support for dynamic properties entirely.
I support this RFC and I like the end goal to be to remove the dynamic properties entirely. Dynamic properties are just confusing for beginners. “This is how you declare properties, the scope, the type, name etc.. but you don’t have too…” I also remember that I’ve fixed more than one bug because I misspelled a property name. I understand there will be an impact on legacy code but there is help to find dynamic properties (static analysers) and there is also a clear upgrade path. // Tobias
  115876
August 27, 2021 05:19 mike@newclarity.net (Mike Schinkel)
> On Aug 26, 2021, at 11:02 PM, Pierre Joye php@gmail.com> wrote: > I don't know how others feel about it, I think most want to go the > path to (2) and a more strict, if not almost fully strict PHP. Core > devs to simplify the engine, users to allow them easier checks and > safety in their frameworks or libs. End user don't really bother as > far as I can see. We may have to decide once the long term vision for > PHP and then do the changes accordingly, and more importantly, with > consistency.
I tend to concur that path (2) would provide the better outcome. However, eliminating dynamic variables would be eliminating the ability to simulate a(t least one) language feature that some (many?) people have been using dynamic variables to simulate. Maybe as part of deprecation of dynamic variables we should also consider adding this(ese) feature(s) to the PHP language? There are two approaches I can envision, Both would better enable the S.O.L.I.D. "open-closed" principle in PHP. 1.) Allow PHP class declaration across multiple files — A use-case for this is what I think is effectively the command dispatcher pattern where properties contain instances of classes that might be contributed by 3rd party code to allow those developers to access the instances by named property: e.g. $cms->map->display() where $map is added by a 3rd party library to the class for the $cms instance before $cms is instantiated. See: https://gist.github.com/mikeschinkel/ed4f9594c105dae7371bfce413399948 Some might view this as "monkey patching" but I view it as a more structured approach, like C# partial classes. 2.) Allow trait usage for a class from another file — This is just a slightly different spin on #1. See: https://gist.github.com/mikeschinkel/5b433532dc54adf53f5b239c8086fd63 Each approach has its own pros and cons but it probably depends on which would be easier and more performant to implement. -Mike
  115872
August 27, 2021 01:19 pollita@php.net (Sara Golemon)
On Thu, Aug 26, 2021 at 3:34 AM Nikita Popov ppv@gmail.com> wrote:
> > The crux of the issue is what our end goal is: > > 1. Require users to explicitly annotate classes that use dynamic properties,
> but otherwise keep dynamic properties as a fully supported part of the core language.
> That's how I initially read your RFC, what I'm hearing here is that your
quite explicit goal is:
> 2. Remove support for dynamic properties entirely. The core language only has
> declared properties and __get/__set, and nothing else. stdClass is just a very
> efficient implementation of __get/__set. > If that's your position, then the `extends stdClass` approach makes sense,
because the dynamic properties HashTable can live in the object's extra data offset block and the get_prop/set_prop implementations in stdClass' handlers are the *only* things which know about dynamic properties. That represents a significant advantage to the engine for the "happy path" of declared properties only. Every (non-dynamic) object is a word (8 bytes) leaner, and the branch points for dynamic property access are limited to the only place they can be used, and where the typical result is positive. Starting from that argument, your RFC begins to look more compelling. I was definitely not starting there on an initial read. I do still have reservations about enforcing stdClass as a root for any class which wants to use dynamic properties. It's messy, but... to paraphrase what you said about going with an attribute approach... yeah, someone could make every current root class in their application explicitly inherit from stdClass without any ill effects in PHP < 8.2, with only the exception of external libraries being a problem. So that's the spectrum: - Opt-in to strict behavior: No BC impact, least benefit to the ecosystem or the engine - Attribute/Interface opt-out (goal#1): Moderate BC impact, ecosystem benefits well, engine benefits a little, but not much. - Extend stdClass opt-out (goal#2): Highest BC impact, ecosystem and engine benefit most. Goal#2 is bold. Possibly not-too-bold, but it's not clear to me where dynamic props are being used today and how many of those places can't "just extend stdClass" for one reason or another. Goal#1 might be a stepping stone along the way to Goal#2, as it will give us something clear to scan for across major frameworks at the very least, but that is going to push us from removal in 9.0 all the way out to removal in 10.0. If you're keeping track, that's gonna be circa 2030 give or take a year or two. That might be dangling the carrot out a little too far... The purist in me wants to be bold. It also wants some hard data on existing usages. A simple grep isn't going to cut it this time. We're going to need to run some static analyzers on some frameworks and libraries. Who's got it in them to do the research? -Sara
  115873
August 27, 2021 02:02 matthewmatthew@gmail.com (Matthew Brown)
On Thu, 26 Aug 2021 at 21:20, Sara Golemon <pollita@php.net> wrote:

> We're > going to need to run some static analyzers on some frameworks and > libraries. Who's got it in them to do the research? > > -Sara >
I'm not volunteering, but I forked Nikita's package analysis to add Psalm scanning a while ago: https://github.com/muglug/popular-package-analysis It's not trivial (downloading the requisite files takes up a lot of HDD space) but Psalm's output can be parsed and analysed looking for UndefinedPropertyFetch and UndefinedThisPropertyFetch issues.
  115839
August 25, 2021 22:05 paul.crovella@gmail.com (Paul Crovella)
On Wed, Aug 25, 2021 at 3:03 AM Nikita Popov ppv@gmail.com> 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/0000-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
I'd like to see a section (or just a paragraph) in the RFC summarizing the benefits of making this change. Right now the introduction says that using dynamic properties in modern code "is rarely done intentionally" implying that it's typically done unintentionally, however I can't remember the last time I saw unintentional use either. Is this a common cause of bugs? The internal impact section mentions saving 8 bytes per object plus an unspecified "dramatic" amount for an object iterated over via `foreach` which sounds nice but leaves me guesstimating at real-world impact. I don't much care for dynamic properties, but I also don't much see them outside legacy code so they're not bringing me troubles either. Breaking working code, however, would.
  115841
August 25, 2021 22:47 the.liquid.metal@gmail.com (Hendra Gunawan)
Hi.

A chunk in the RFC:

    abstract class Constraint {
        public $groups;

        public function __construct() {
            unset($this->groups);
        }

        public function __get($name) {
            // Will get called on first access, but once initialized.
            $this->groups = ...;
        }
    }

Interesting! new to me.

Maybe someday we will have this one:

    abstract class Constraint {
        public lazy $groups;

        public function __construct() {
            // no need to do this:
            // unset($this->groups);
        }

        public function __get($name) {
            // Will get called on first access, but once initialized.
            $this->groups = ...;
        }
    }

Regards,
Hendra Gunawan.
  115895
August 30, 2021 12:13 come.chilliet@fusiondirectory.org (=?UTF-8?B?Q8O0bWU=?= Chilliet)
Le Wed, 25 Aug 2021 12:02:49 +0200,
Nikita Popov ppv@gmail.com> 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
If I understand correctly the RFC, in these two classes: class A { public $prop; public function __construct() { unset($this->prop); } } class B { public $prop; } The property $prop is not in the same state in the end? What is the difference? isset returns FALSE for both, no? And property_exists? Is it something that was the same before the RFC and would be different after, or is it already two different cases and how? Côme
  115896
August 30, 2021 12:37 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Aug 30, 2021 at 2:14 PM Côme Chilliet <
come.chilliet@fusiondirectory.org> wrote:

> Le Wed, 25 Aug 2021 12:02:49 +0200, > Nikita Popov ppv@gmail.com> 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 > > If I understand correctly the RFC, in these two classes: > > class A { > public $prop; > > public function __construct() { > unset($this->prop); > } > } > > class B { > public $prop; > } > > The property $prop is not in the same state in the end? What is the > difference? > isset returns FALSE for both, no? And property_exists? >
In the latter case, the property has value null. In the former case, it is unset. In both cases, it is declared. Accessing an unset property will trigger __get/__set. Accessing a null property will not (assuming it is visible). Is it something that was the same before the RFC and would be different
> after, > or is it already two different cases and how?
This RFC does not have any impact on this behavior. This is a "standard" pattern used for lazy initialization. Regards, Nikita
  116263
October 12, 2021 10:23 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov ppv@gmail.com> 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/0000-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 >
Based on the received feedback, I've updated the RFC to instead provide an #[AllowDynamicProperties] attribute as a way to opt-in to the use of dynamic properties. As previously discussed, this won't allow us to completely remove dynamic properties from the language model anymore, but it will make the upgrade path smoother by avoiding multiple inheritance issues. Especially given recent feedback on backwards-incompatible changes, I think it's prudent to go with the more conservative approach. Regards, Nikita
  116264
October 12, 2021 13:52 internals@lists.php.net ("Levi Morrison via internals")
> Based on the received feedback, I've updated the RFC to instead provide an > #[AllowDynamicProperties] attribute as a way to opt-in to the use of > dynamic properties. As previously discussed, this won't allow us to > completely remove dynamic properties from the language model anymore, but > it will make the upgrade path smoother by avoiding multiple inheritance > issues.
Quoting the updated RFC:
> We may still wish to remove dynamic properties entirely at some later > point. Having the #[AllowDynamicProperties] attribute will make it much > easier to evaluate such a move, as it will be easier to analyze how much > and in what way dynamic properties are used in the ecosystem.
But in this place it does not mention PHP 9.0. Other places still mention converting it to an error for PHP 9.0. Is that still the plan?
  116265
October 12, 2021 13:59 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Oct 12, 2021 at 3:52 PM Levi Morrison morrison@datadoghq.com>
wrote:

> > Based on the received feedback, I've updated the RFC to instead provide > an > > #[AllowDynamicProperties] attribute as a way to opt-in to the use of > > dynamic properties. As previously discussed, this won't allow us to > > completely remove dynamic properties from the language model anymore, but > > it will make the upgrade path smoother by avoiding multiple inheritance > > issues. > > Quoting the updated RFC: > > We may still wish to remove dynamic properties entirely at some later > > point. Having the #[AllowDynamicProperties] attribute will make it much > > easier to evaluate such a move, as it will be easier to analyze how much > > and in what way dynamic properties are used in the ecosystem. > > But in this place it does not mention PHP 9.0. Other places still > mention converting it to an error for PHP 9.0. Is that still the plan? >
The current RFC proposes to make dynamic properties an error for classes without #[AllowDynamicProperties] in PHP 9.0. On the other hand, classes using the attribute will be able to continue using dynamic properties without error. (That is, as usual: Deprecations are converted to error in the next major version.) Regards, Nikita
  116266
October 13, 2021 01:43 tstarling@wikimedia.org (Tim Starling)
On 12/10/21 9:23 pm, Nikita Popov wrote:
> Based on the received feedback, I've updated the RFC to instead provide an > #[AllowDynamicProperties] attribute as a way to opt-in to the use of > dynamic properties. As previously discussed, this won't allow us to > completely remove dynamic properties from the language model anymore, but > it will make the upgrade path smoother by avoiding multiple inheritance > issues. Especially given recent feedback on backwards-incompatible changes, > I think it's prudent to go with the more conservative approach.
I think it would still be the biggest compatibility break since PHP 4->5. Adding a custom property is a common way for an extension to attach data to an object generated by an uncooperative application or library. As the RFC notes, you could migrate to WeakMap, but it will be very difficult to write code that works on both 7.x and 8.2, since both attributes and WeakMap were only introduced in 8.0. In MediaWiki pingback data for the month of September, only 5.2% of users are on PHP 8.0 or later. Also, in the last week, I've been analyzing memory usage of our application. I've come to a new appreciation of the compactness of undeclared properties on classes with sparse data. You can reduce memory usage by removing the declaration of any property that is null on more than about 75% of instances. CPU time may also benefit due to improved L2 cache hit ratio and reduced allocator overhead. So if the point of the RFC is to eventually get rid of property hashtables from the engine, I'm not sure if that would actually be a win for performance. I'm more thinking about the need for a sparse attribute which moves declared properties out of properties_table. I would support an opt-in mechanism, although I think 8.2 is too soon for all core classes to opt in to it. We already have classes that throw an exception in __set(), so it would be nice to have some syntactic sugar for that. -- Tim Starling
  116267
October 13, 2021 08:05 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Oct 13, 2021 at 3:43 AM Tim Starling <tstarling@wikimedia.org>
wrote:

> On 12/10/21 9:23 pm, Nikita Popov wrote: > > Based on the received feedback, I've updated the RFC to instead provide > an > > #[AllowDynamicProperties] attribute as a way to opt-in to the use of > > dynamic properties. As previously discussed, this won't allow us to > > completely remove dynamic properties from the language model anymore, but > > it will make the upgrade path smoother by avoiding multiple inheritance > > issues. Especially given recent feedback on backwards-incompatible > changes, > > I think it's prudent to go with the more conservative approach. > > I think it would still be the biggest compatibility break since PHP > 4->5. Adding a custom property is a common way for an extension to > attach data to an object generated by an uncooperative application or > library. > > As the RFC notes, you could migrate to WeakMap, but it will be very > difficult to write code that works on both 7.x and 8.2, since both > attributes and WeakMap were only introduced in 8.0. In MediaWiki > pingback data for the month of September, only 5.2% of users are on > PHP 8.0 or later. >
Just to be clear on this point: While attributes have only been introduced in 8.0, they can still be used in earlier versions and are simply ignored there. It is safe to use #[AllowDynamicProperties] without version compatibility considerations.
> Also, in the last week, I've been analyzing memory usage of our > application. I've come to a new appreciation of the compactness of > undeclared properties on classes with sparse data. You can reduce > memory usage by removing the declaration of any property that is null > on more than about 75% of instances. CPU time may also benefit due to > improved L2 cache hit ratio and reduced allocator overhead. >
Huh, that's an interesting problem. Usually I only see the reverse situation, where accidentally materializing the dynamic property table (through foreach, array casts, etc) causes issues, because it uses much more memory than declared properties. Based on a quick calculation, the cost of having dynamic properties clocks in at 24 declared properties (376 bytes for the smallest non-empty HT vs 16 bytes per declared property), so that seems like it would usually be a bad trade off unless you already end up materializing dynamic properties for other reasons. Did you make sure that you do not materialize dynamic properties (already before un-declaring some properties)?
> So if the point of the RFC is to eventually get rid of property > hashtables from the engine, I'm not sure if that would actually be a > win for performance. I'm more thinking about the need for a sparse > attribute which moves declared properties out of properties_table. >
The ability to opt-in to dynamic properties would always remain in some form (if only through stdClass extension as originally proposed), so if you have a case where it makes sense, the option would still be there. Regards, Nikita
  116268
October 13, 2021 08:19 rowan.collins@gmail.com (Rowan Tommins)
On 13/10/2021 02:43, Tim Starling wrote:
> I think it would still be the biggest compatibility break since PHP > 4->5.
I think this is a rather large exaggeration. It's certainly a use case we need to consider, but it's not on the scale of call-time pass-by-reference, or removing the mysql extension, or a dozen other changes that have happened over the years.
> As the RFC notes, you could migrate to WeakMap, but it will be very > difficult to write code that works on both 7.x and 8.2, since both > attributes and WeakMap were only introduced in 8.0.
Firstly, writing code that works on both 7.x and 8.2 will be easy: ignore the deprecation notices. As discussed elsewhere, treating a deprecation as a breaking change makes a nonsense of deprecating anything. Secondly, I would be surprised if libraries using this trick don't already have helper functions for doing it, in which case changing those to use WeakMap and falling back to the dynamic property implementation on old versions is easy. Maybe I'm missing some difficulty here? if ( class_exists('\\WeakMap') ) {     class Attacher {         private static $map;         public static function setAttachment(object $object, string $name, $value): void         {             self::$map ??= new WeakMap;             $attachments = self::$map[$object] ?? [];             $attachments[$name] = $value;             self::$map[$object] = $attachments;         }         public static function getAttachment(object $object, string $name)         {             self::$map ??= new WeakMap;             return self::$map[$object][$name] ?? null;         }     } } else {     class Attacher {         public static function setAttachment(object $object, string $name, $value): void         {             $attachments = $object->__attached_values__ ?? [];             $attachments[$name] = $value;             $object->__attached_values__ = $attachments;         }         public static function getAttachment(object $object, string $name)         {             return $object->__attached_values__[$name] ?? null;         }     } } $foo = new Foo; Attacher::setAttachment($foo, 'hello', 'world'); echo Attacher::getAttachment($foo, 'hello'), "\n";
> I would support an opt-in mechanism, although I think 8.2 is too soon > for all core classes to opt in to it. We already have classes that > throw an exception in __set(), so it would be nice to have some > syntactic sugar for that.
I proposed "locked classes" a while ago, but consensus was that this was the wrong way around. One suggestion that did come up there was a block-scopable declare which would allow manipulating dynamic properties, even without the target class's co-operation. However, I think WeakMap (with a helper and a fallback like above) is probably a superior solution for that, because adding properties outside the class always carries risk of name collision, interaction with __get, etc Regards, -- Rowan Tommins [IMSoP]
  116269
October 13, 2021 09:17 guilliam.xavier@gmail.com (Guilliam Xavier)
Off-topic:

if ( class_exists('\\WeakMap') ) {
>
People should stop using a leading slash in FQCN *strings*. \Foo::class is "Foo", not "\Foo". It might work generally but that's asking for problems (e.g. for autoloaders). (Sorry.)
  116270
October 13, 2021 09:21 guilliam.xavier@gmail.com (Guilliam Xavier)
On Wed, Oct 13, 2021 at 11:17 AM Guilliam Xavier xavier@gmail.com>
wrote:

> Off-topic: > > if ( class_exists('\\WeakMap') ) { >> > > People should stop using a leading slash in FQCN *strings*. \Foo::class > is "Foo", not "\Foo". It might work generally but that's asking for > problems (e.g. for autoloaders). > > (Sorry.) >
And of course I mistyped "leading backslash"... Also externals.io seems to strip them, so: \\Foo::class is "Foo", not "\\Foo".
  116271
October 13, 2021 09:52 pierre-php@processus.org (Pierre)
Le 13/10/2021 à 11:17, Guilliam Xavier a écrit :
> Off-topic: > > if ( class_exists('\\WeakMap') ) { > People should stop using a leading slash in FQCN *strings*. \Foo::class is > "Foo", not "\Foo". It might work generally but that's asking for problems > (e.g. for autoloaders). > > (Sorry.) > And why not ? using the FQDN is 100% valid, autoloaders should take care
of this, not the end user. For what it worth, I'm using both, depending upon context, both can make sense. Regards, -- Pierre
  116272
October 13, 2021 12:42 rowan.collins@gmail.com (Rowan Tommins)
On 13/10/2021 10:17, Guilliam Xavier wrote:
> Off-topic: > > if ( class_exists('\\WeakMap') ) { > > > People should stop using a leading slash in FQCN *strings*.  > \Foo::class is "Foo", not "\Foo".  It might work generally but that's > asking for problems (e.g. for autoloaders). > > (Sorry.)
Hah, good point. I should probably just have just used ::class anyway (in which case the leading backslash is the quickest way of the sample code being pasteable into some other file): if ( class_exists(\WeakMap::class) ) { There's probably a bunch of other style no-noes in that example, but I did at least test it worked. :) Regards, -- Rowan Tommins [IMSoP]
  116273
October 13, 2021 13:18 pierre-php@processus.org (Pierre)
Le 13/10/2021 à 14:42, Rowan Tommins a écrit :
> On 13/10/2021 10:17, Guilliam Xavier wrote: >> Off-topic: >> >>     if ( class_exists('\\WeakMap') ) { >> >> >> People should stop using a leading slash in FQCN *strings*. >> \Foo::class is "Foo", not "\Foo".  It might work generally but that's >> asking for problems (e.g. for autoloaders). >> >> (Sorry.) > > > Hah, good point. I should probably just have just used ::class anyway > (in which case the leading backslash is the quickest way of the sample > code being pasteable into some other file): > > if ( class_exists(\WeakMap::class) ) { > > There's probably a bunch of other style no-noes in that example, but I > did at least test it worked. :) > > > Regards, > I am surprised that:
if ( class_exists(\WeakMap::class) ) { Actually works when the class does not exist. It's not really surprising, I mean the FQDN::class in the end only resolve to a simple string no matter that the class exists or not, but, I'm being the devil's advocate here, there are use case were you would want the engine to crash when you explicitly reference/use a non existing class, even when it's only its name. I'm sorry this is off-topic. -- Pierre
  116314
November 10, 2021 14:31 nikita.ppv@gmail.com (Nikita Popov)
On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov ppv@gmail.com> 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/0000-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. >
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. Regards, Nikita
  116355
November 15, 2021 09:52 derick@php.net (Derick Rethans)
Dear Internals,

On Wed, 10 Nov 2021, Nikita Popov wrote:

> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov ppv@gmail.com> 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
  116367
November 15, 2021 12:51 Andreas Heigl <andreas@heigl.org>
--C4Xq0uG20w1jPRz1KzEy3YghGXvIa3LQT
Content-Type: multipart/mixed;
 boundary="------------4EA4DA2EF1CC261F57DBAC43"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------4EA4DA2EF1CC261F57DBAC43
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hea all.

On 15.11.21 10:52, Derick Rethans wrote:
> Dear Internals, >=20 > On Wed, 10 Nov 2021, Nikita Popov wrote: >=20 >> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov ppv@gmail.com> w= rote:
>> >>> 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. >=20 > The voting is now open, but I think one thing was not taken into accoun= t
> here, the many small changes that push work to maintainers of Open > Source library and CI related tools. >=20 > 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. >=20 > 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. >=20 > Before we introduce many more of this into PHP 8.2, I think it would be=
> wise to figure out a way how to: >=20 > - 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 introduc= e
> BC breaks and deprecations. >=20 > I am all for improving the language and making it more feature rich, bu= t
> we have not spend enough time considering the impacts to the full > ecosystem. >=20 > I have therefore voted "no" on this RFC, and I hope you will too. >=20 > cheers, > Derick
After some thoughs on this RFC I have reverted my original vote and=20 voted "No" due to several reasons. For one thing it is not clear to me what the benefits are. Yes: The=20 language evolution RFC talks about "Forbidding dynamic object=20 properties" but it also specifies that "there is also a lot of old code=20 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=20 hundreds of lines code less to maintain. On the contrary. There is more=20 code and more logic to maintain [2]. So when the only reason for the change is that one line in the RFC ("In=20 modern code, this is rarely done intentionally"[3]) then that is not=20 enough of a reasoning for me for such a code change that requires a lot=20 of existing code to change. Those that want a cleaner code can already use static code analysis to=20 find such issues (if not, I'm sure that there will be some analyzers=20 around before PHP8.2 will be around) or write appropriate tests to make=20 sure that they do not use undeclared properties. While I personally would really like to deprecate dynamic properties I=20 believe that it is the wrong thing to do for the language. At least=20 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=20 the RFC? [1]=20 https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-langu= age-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 --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --------------4EA4DA2EF1CC261F57DBAC43 Content-Type: application/pgp-keys; name="OpenPGP_0xA8D5437ECE724FE5.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xA8D5437ECE724FE5.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFzEA7MBEACpvo0AbmZG6lUGMvDUebQcYVjOPrdqtnlb2WoZH9FrJyHyenzejO29VCjue= kdh u44sUNgEHXxExUekguLDGZOzC9926g2rGDWO3MU1oqRlKURnOWsp/i0d9WM07ihj/lL6smT9Y= Lea gtPCJporUiFW8JyIusBWWhlL8hp8ZDvEfmvi06xDXML3wXzH/KWmoew3LgdwCZPkQSIWemUDP= ZKc UL8eeVkhYIJA9VKQnGSx36p5T7Ch/l+iqiPlyY1GUNItX9AQjpr07V0kIjyK+yHn6Aw1uy1xW= rLn 7ATDX8YuMvaz72+c/P2zQReMWoZNfggd2FHOPRUHvHcC9C91PuzJh8e9hvtU/szDrPvvCVpg5= aRy mN/YPFJBSEqZfDelhD+8A1TJNPqSyzc21Qdd61636ynryawIW+HxFT/UN1eA7V5/fdjeRyNUJ= d7B 99Vo5A/lI25bIpg6cPLOLpVPFHEpNlGPQ8pcMRwnjG9GR74PTfH7Dy8Ksq8lpygPljJInZbz0= 870 cHlM5XSdIPTXWQFfJi0e2kfaLCEni/Vih+eL0e5F7X3RtaXY0HRFYHX8dY7ojf3sZJjdPVm3A= QXY 1yNkjnRxyJ/4gIwdFwYplU6lRBL92jdDLavPWVK4Dsil/woKmsCpxClWfU/MzmQlhbdH+x8V2= SYO a4aJWiixx59DxQARAQABzSFBbmRyZWFzIEhlaWdsIDxhbmRyZWFzQGhlaWdsLm9yZz7CwY4EE= wEK ADgWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQDswIbAwULCQgHAwUVCgkICwUWAgMBAAIeA= QIX gAAKCRCo1UN+znJP5clsD/4vnmCp5oVIXdNXkK3PNajHR1ddpr2+Ake+bo6TS801MSd638f2U= g/e Qmu6j0XuHbgJql9wnoDh0Oq47bPxGTszPbbhD0FL1s6YBDqJKcz2okbmYRutumC52u4h8dGxb= VjC M9le1rckK54aDjkzL27iGRNfQLw1vg9gdl1yRz866bZ75MItk/7BewJrodQ5zweNcDVOmYseP= Lpo 13peB1mzDP/tuBH4CpoeDtAb/+Rc5Qv/J6P7iMDC4fPbFIl5//Ge7blMV98seXOAYMCvDYmLc= JFb nESBla/8te8lKE2E1PjwnIeMvDfYHn17CYd2UqnmlQbJbN30/Y2eiPT9w7wjrgc+qGRWEU+hu= GMl rDXQmmAtHPADf08QwOWpDVoZ+WFsQEB3f2fsZtfOnxXv8yb+Q16kVcPWaRyvusT5KLT39h2Vv= Zlh H8uporNimjs7+Rl8Fs7PP6n2L+OCnI1sSCTixBQT4MDNM6IVxqhy5j8M9ig3vR7czJgVVsDmK= CFi gOibvIFgxfRH2A7JjyplO034eUw7I3IJdffuBWjZ8SCfwZ3sS67UaPy01UVovSQKikEJBfADE= cl4 X25YsHvHXCksYLoZHb6wvtFzUrjxXwipwzlWtNBR2gTB2lCfeCLcwYcHdN8qcgg+emxDkBHeL= /Ml w5OLGW86dy6ha3BJDQgdL8LBcwQQAQoAHRYhBJZ8z6UN/+4Du4v18sqSE8db/ORyBQJcxBvDA= AoJ EMqSE8db/ORyHLUP/iADAMreqincMvKf8A0BMhAl79ZFhXkcFeEvb7KreVNp9pFBqUMtpvD6M= wY8 MpX+B9ys7qL8uY01Mf4ovex+O3tDmRRDMtho7Af2bO7Dyku7gnjtR0qdb+ceMDyVbmODVoMN+= Sh8 a9bj0uY0BlCsOkDb6hYyIf1xXAHkrX4wZbbjzpwNWoTQxsJo5ho7V/7CXMBYL6nLYpXR7vmgU= ori 2FbmiDIu+sKWbDezWcTNXItkn0WpIGTGSPWMLzEIJznOFJZlBd2q+/YHKqO/3G53tl62XLBjj= 9TC u1cnScsFJKhVRjn/mcwI9rrg4tLuSIfGqAoq29YSd832r9iC8CBuHc/T7MySekxNrdxnpecHy= Ajw AI+RhF1g+fVrmeYt1+4stwfpmLp+gEFPiHxoQkKc2q8pjNRmtoKvf2Z9cqauB+8QWyIKjgrab= dJy ev/b54o+CqxNo4KSjhwSBjb/ihVw1W2AWLkEGJUysHP6r1E12dXlYrEvBm13LIP+OOqpZRY5K= MKi WNjmQF3wtEr6SjMYXcLx+1ydVQLqFa6in57YotfNqlehiU1KDhJ/AyU+tgBJ3OxShS6p4Gmia= Dvh 8qDp0bm7GxkQEA+8kOmn+4mY5E5LzzlbIkHoDqqZs/RkWoxNpXyhIx6zqqlE4yASuWwY98tco= mx8 /CClg5DoQAl2NvWPwsFzBBABCgAdFiEEclTRxmnDsSbzEk7xbQJ8ZCRit3gFAlzEHMsACgkQb= QJ8 ZCRit3jsmA/+JJUt4Bg9cJ3itTdP+0PfSVYh0xwR+ev5b0sAj2moWowk1U0IEzHhM5eHlAJ/5= s4/ peG2Bkv2vCB+mTMFCbcuZfdsF1N13MSFqJH9ZLjZY5QGo9IqAF+JI1Tu0zArKOXWI+Fs4WXaY= lp2 f+aMccVrd6LIObbgKKQzH2n4u3nxwfVsWSZcNVCvIQVI9FPexH9C4EbPN/ocxx4/Qewx/ie+s= slL M8CVULcZmJeN+rcjWR4hr2l9zY925WpbQ/LE6cmnqDWVS+SgFQGF6j1nsUJzRA2pYk/Q12o+2= ka9 1/o9pPu3Z8gEFu7ljflT3iO4G139crRNXRE00qfBQft9VvMl02iGQlCbK1ZER8Rou5yDPjfBk= MHP DoSUa45ILQqsUB/3rKT08ApA80QkgCh+cTyhvVCrZJPKWjusRn8mX9FM+lotL9ZWID9/Q90FJ= hli XyPj8gmsoFh+37/AV+Wl2jcNbG1CIzX1cx2KJ+2AWciBlE0046ztGuaHzpqzjeyvwxUHYTDJh= 2+t DyRCt7lrRrZuMTBlHCQw1GlSSrlPw9l1CASXto0gxnFgCpulTBHJQVPUr0XbjmT52xbmRlv3y= 4CR MCp+/0ZKzXddKZTA6XyIHuumRuKW0L1rBIfqgbUB0icE7tM/+bkYZzMExhnILF05nIIQKN5Rq= 59p t+KxrjK2t13OwU0EXMQFSAEQAL++X487itN2+5NbNK0O2iUkG6OOCK8Uiep+KpWwsfwf8rz5U= FUx Tn2EBfiTRCd9NXEMeiptjp8zsRVN2MSEv77a+aiMahUyIbI+4PUX+Y2fZRIXx7kpTn4T817iw= 19m FrSQ6c/qI88JUvmMA/r9FYbUAh0vjZEPc+WUmPnZYCShnna0pDhiJe1b3pjoxPTNA2arBkGhm= m1x th/rKN80Saf77ZtxOpRx+wiwXAKG54B6Q9fVWUzT5pRzJFPl6UEt4WaWVA8kMkbjLcv8k3fJT= MK0 ZpxjTIDFIqqYxiJIKE5TbuMvN9ilx/grUhdQ+Nu5kOJlOUiFfeqTUi/hJOljtRsh3WxJhpEmV= u+w 7/PJpLPPys1Xa7Ax6DHr/nR5iNL1tDZEjrW6/Wav7AYX8OnlZF6irml7APAusOfv4XemZfUb/= qva /pQjbJpeVYmedFyGgC96yR55bRbzXI4CHMvApRFxyUekQp09h49MvTNJ0dV3Uj9+V+PMS05OY= BIs KbRv+C9QaoCiuUK83BSd0XFvR1KuO3FRY3Dtc5zrdWuGNa0tUYAd82Dnu/pR1wmdyYdbXEcQH= uW0 Vx5Dm6TDQ1ZLNEh2ZZRqWQ8Qrppb3n5lhbjyNiPO0upJlxYl3qo6mRXzuQMoZOeH50ZPyqmZu= d+Z kHfg/Sq8PRHNdlBhtIZ6/FBTABEBAAHCw6wEGAEKACAWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5= QUC XMQFSAIbAgJACRCo1UN+znJP5cF0IAQZAQoAHRYhBDh6O3rdFXWZPESSt+BX/kgit7ZFBQJcx= AVI AAoJEOBX/kgit7ZFM28QALr4HOTaNkpLZMxJAECLxFQg8Yzg9GdUE4l6Xqeea+Qz6Hv2fO0AV= 8VQ ug7h7mFoAQQwG0lK5yHa/RF3tcApVEXMyL19AamMNnA5H0mXEUcTvge2JeVK9ONTBYjSR6llO= nUK Co24p3lnzmp6eZNEfaTPbSGo7UTmWcqfHtkvH4C5hOhDyY6GTVrgcMV2G2B1jq4evn0XxdqTi= po3 VyAMtwW/HlTHKXpXpW0QhzD+D6ioNUgyQjpPjkI3BWJHzSCWVUKgWD2EdOu+IsciDM115APvd= yeX vgWNF8jphl+PJf2inqS8iSrd4pf04//tqNhkmBHSIFh6LwPlUUMEjKI4sWUYcL8zZimUmaK9H= yZe bZq+IQFnjMw80h4iMc4YpY8mKgz4ld7wNV68+NFpgn+YaK6EVCpML91ret5kR4PyhO3tlMydY= zW3 SFmmYFIEOEn+l5V223/8RDsg7XilBPZXtYDDpCJSedo3+d9eeBTyLnaXhnmhs1N06IVMbga/x= g6B YT0OxJ7KFhyLW9SQ2+22oVqtfqGR9+Qx8UaiLnAx2a0ZjCHOspg/RTsXz7jqC8Ez9AVEPLOrw= /It IFI8Mx1AoJxfdoK9JIIsSNHeKrvCNmRK1n7NnNLa1JDRXYNgxsCD81YJzpQjtUC4KBKbFevs/= MHD Ksg/o2mlfeNy3AAEYckW7aMP/AjhDWZuUB+WoPnVO3qoaRdtt4aMRI+8Vjwsci3HHcueQa7Xs= S/J fzg85MUXqN7PozrfEBgwk5Z+kdFW+4dhiaEXntEqWUgwkExJ5ysmP597WIQG2hUpX0jwkrzdZ= q6r Z/87mHCAMgFk1Lg/6oPOQqXvBdLFlMo6RIPawC8EeROcIuszvzKR4GIEIyXyR5rflLUUFfvLr= NPk MeuxA5CKoN1IidlngMO/sH58aac2Z67k7nrNQk62QeMFQndcKb45Pt3bgPjDSB98hlAklKzuH= kxx lwreilFcBqx/8f1qeg3tTkF29RkSaP38K9RnLhrfRrt4Tz8fKTF/C6A1HqL2dMQmto14S8U2o= zq9 3xiu0oUpLFdOoqfqPxgiqbqWUFIAY4JS4J2o9HXwjFii6X7/VJ9Yj0DNCrZytvSRR24j6p2r2= HFg fEPDs6NFPGoF9vNksJhc1FViEkjt1z5vTdmu3+DRSD3QTpRUujVnUL8jr0ggoZ3CI6qjVqb8K= 2+d dubT9SxWKNbBOcNOwGtqQtw2z8FZ/2tQOvu9A44A5gCYJ5fHj9uvcvEKJe6X7hX7WBpAItZUe= Y8x D91uNSY2/uceh0pE6APHxNMRaLCKMRpyvRCHqRbA2iiLT0qF4pmwYUtYIig1TkNczbtzj38mv= H+G OQ6onUMxyW18qrqJn8LzvlhkzsFNBFzEBbgBEACo/XIhTsNMVM1XLI2qzKWWLIIIYN/uTcoum= h0A eh98saWYjg68H/fv2CZhF0CZ7JXcW3EqCjWzLnHiGXTMumYwCm5vgxic1uHTS6tv97hNPNA80= vKK Fgs/ofYM4MtzQWdLw/c7lzF6qomhbr9woKbYgwRnp8qh2C84aH6+OQv6I1t2fWE7qhoLMrSh2= EiK xeogXkyNqKzlRibBUOsjurTXg+UJt7NEnrp/qgm1m9zhAkMoadFs5bROEb24qZ7eDij1HmrM6= mUb 4OkL2PnDzkUBJ2At5otp+uUCJrATS2tAz0OGNu3ijJP94+Y1d3Nt6jC5pAI40ZcxSXMMrLFAT= XJi NYLaD/Y6tpLgXaLQF1krgtvcGVkxJ8/fJVrKVcmF8Cfnab+rbNDIxLAwWT+dor2BwDgRoRI45= cyG XB7YHstdk9kBUZqff1BrMZLGEmp+M6xE2wFPWan4kD2oIh5B14CKUMYB+CBmMlJhkIzBl2GvO= 3Hv VyywCk2EourRxjDocZxyajE/fwFuAK5emuFKrucMmsnxzZMMJdkoJmnozsBS9Oj9e8YiR+yAM= Dex x4152G6SOCR9JSxnFUBPEKOgabIPLY3eQfn0nBdh/mr/iKSg+5zj3bsbvUetvRFdTbUTFnqss= L7b 3Q5ydaL3Q6PjCO/Fe0bmLKXnY2AzY8emb3xc/wARAQABwsF2BBgBCgAgFiEEWe7QZoa1zQB2l= HAN qNVDfs5yT+UFAlzEBbgCGwwACgkQqNVDfs5yT+XL9w//VJKq2qxGxS1IGSaaowcneiRx88ZfB= Tzk takhbqXhnWFwP9vuTaHcSzRowFIVzea55k/5mQeKuTTEt7k0Yb29lwoT+iqi12V/73EBIaUK+= JT5 ZP28bnQXkkqqpRzcro4lDzi5geamt7KMsWDmYqCHyXU2xXeALnqfLv1jfsJJMeoDzLl8ql50q= m1z +u94VOXf94dlqmV9v6QWoxww2k2xNWBAeUD2YzUXAZncpXbCK1MIRFBHmbg4HAapmpFUewPfs= O4P pUEJqG1IA6rl9csZnc97BvCCha6SZMvXGrEIi/ajNfD0mU2p3Iy5F1UXNx9yJlMziQvqUziA7= MSW olT2ZYr/unSrckXUh7lAwE4tq8RhhXZ2cjL+5ubk/xGFBJycn+YKoT5gmZ+gwGrluN0VJFogf= pY2 RJbF8j8VbUR+vGKxlusgyeC7uEFAoVsIUJFQ3QaPtGmnIZgP3KSz7HsZkAwiXHJ5P6wpH3CWM= u4J aOQlOMo0NPxRZOvtfAkdDb+i4jd+YjvuJkJlur1p6yhu/02cE7/BoDONgATHZqFmYzubWtCU9= Lrf q1RnVBVnH/hLM2IxMGyBYsNDRW3FwSZh7nj6vxjijS9KsxwNiAFzNl78BKlIkHgAjWVDejezm= ncB 5ixg8G0GzKxIBt3S5nrkQNz3HBJEuIwmP7HyMbLbG27OwU0EXMQF6wEQAMUl2EK3LUUh6uunJ= 55v s0z8D0XZFpgm6cwVJgaWw+1H/bXJQR56oosOf+WUM0x1jhBVTLhI+oOK+uz1VkeZRMvTRxYob= fNq n7V5Gn8D8tO8z55yuHgHxn8T8+ZV8RzEbITDNmnK3VNC+mGvWCOe03gU6rhaE9qb3fhFreQA1= e85 XR3WqwxR/m/Vxdc0ANxgrij+VEOZDzlknAt9s93sPQDCqCGfNtRaKgVi/xvZUWvrYSBb1v5d3= wit KlADmuqWCWtc9+PuBmjUIObGP7Zll1dQ6enrtQ943ZsUujXYsdrfuaf5m47u/1G1IzwznIJwl= ZUU M2RAHQkCu+yjnXjtW0/ZEYV0RV+xZ5Qf2CtSq2rS5jpPKbtqhkzclX6ziV2ycRypR/vtbo81U= dP1 cbwSlSlxwp65Y7D+uV1F/7vI+OjUqJpD8mHgdh9OOZCWI2zHTSaH2FqS4LaT6kJIcd0sLoRPV= C3E U2vQQIM5aMyYpFlacZgmAryldp8cHwvbtpR4R2GWlXAW3w/pz2B7BD+xiUHvu2cXgeRYWgvtA= 7kw monmnhJ0NiN6cB4GPjr0ivysDNvdnnvCQ2FNMrqUGMhAK1fFh3nJF5CgMGZSyricZvE8tl7nl= XN4 TUlhhNqhSKyqHL7b0WjPhAUBNZvf1hutnl72rDAMBhTjYbEkLAl2/I5RABEBAAHCwXYEGAEKA= CAW IQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQF6wIbIAAKCRCo1UN+znJP5d4OD/9YMP8rUtR43= z0v Y1UnqMyZH9I8mOIL12AqRhsroaFb8rs3QU+u5cZGf2QvP2uOF6wFzjQGelZLjgVmctBYzutzs= jzX Id0D+B3O2KJhquRXEZ5HQlvZ6/YY0KDzNcYk2Tghg/NqvGltJtJuHrysPIL/0csA91mVUFs25= iap RwLrZfizTEzyh8KCrsV8j+c7r/UTRNkwDbTuq+s7kAyLVEWMTlBRkXg9IsxyX1F+k6xjSKRGf= XnI cct2BEYDcwNxzcPDOHpwzNCH3DCGDmuOLQGspp40liJ1cY1B7a1t3kpNRUv2YDth+jHs58BmF= Nfx WrBwv8OYulI+ehtErPTmOt6eNBhMp5EvoQuT6YwnL+2UwnA1SdNseG1y6tmgeEl/1PeGuYnze= vgk olNUS+4jzyWMG5deRldsjlHxMJBdT5VQXlXP8xb8oHQAkeR3KtlNyrtCi4R62btnIoSF7W9NY= heG aXXa2rHTVi82pqIg6p/E35MVh7X5nXIVOlGM6YXrdKapL/tRNExAW0xfrtwSJfMoxNAqFcwyR= e+i f3/7YeeVW9uqs8gSzAqD9x7JAYI2eW3JW6N3bdiZxIJ7wuk67zaW5rh36h9FhRM9KONvWbzXD= KN2 qyGMI8nCoorTHcnGOw8TqLh9cni59kQ+lEw/6d/vglsWEWhDJdt9r3ZWpMJW9w=3D=3D =3DQgWh -----END PGP PUBLIC KEY BLOCK----- --------------4EA4DA2EF1CC261F57DBAC43-- --C4Xq0uG20w1jPRz1KzEy3YghGXvIa3LQT--
  116369
November 15, 2021 13:19 rowan.collins@gmail.com (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]
  116370
November 15, 2021 13:27 Andreas Heigl <andreas@heigl.org>
--5JRW4rOsjUnAPJYc1xZXZjEKT6bVLIu2P
Content-Type: multipart/mixed;
 boundary="------------D6C6A0814B94472EDB9059EA"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------D6C6A0814B94472EDB9059EA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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= =20
>> the RFC?=20 >=20 >=20 > All votes require a 2/3 majority as of=20 > https://wiki.php.net/rfc/abolish-narrow-margins
Thanks! I just stumbled over the fact that some other recent RFCs still had the=20 statement "requiring a 2/3 majority" in the "Vote" part which I was=20 missing here. Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --------------D6C6A0814B94472EDB9059EA Content-Type: application/pgp-keys; name="OpenPGP_0xA8D5437ECE724FE5.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xA8D5437ECE724FE5.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFzEA7MBEACpvo0AbmZG6lUGMvDUebQcYVjOPrdqtnlb2WoZH9FrJyHyenzejO29VCjue= kdh u44sUNgEHXxExUekguLDGZOzC9926g2rGDWO3MU1oqRlKURnOWsp/i0d9WM07ihj/lL6smT9Y= Lea gtPCJporUiFW8JyIusBWWhlL8hp8ZDvEfmvi06xDXML3wXzH/KWmoew3LgdwCZPkQSIWemUDP= ZKc UL8eeVkhYIJA9VKQnGSx36p5T7Ch/l+iqiPlyY1GUNItX9AQjpr07V0kIjyK+yHn6Aw1uy1xW= rLn 7ATDX8YuMvaz72+c/P2zQReMWoZNfggd2FHOPRUHvHcC9C91PuzJh8e9hvtU/szDrPvvCVpg5= aRy mN/YPFJBSEqZfDelhD+8A1TJNPqSyzc21Qdd61636ynryawIW+HxFT/UN1eA7V5/fdjeRyNUJ= d7B 99Vo5A/lI25bIpg6cPLOLpVPFHEpNlGPQ8pcMRwnjG9GR74PTfH7Dy8Ksq8lpygPljJInZbz0= 870 cHlM5XSdIPTXWQFfJi0e2kfaLCEni/Vih+eL0e5F7X3RtaXY0HRFYHX8dY7ojf3sZJjdPVm3A= QXY 1yNkjnRxyJ/4gIwdFwYplU6lRBL92jdDLavPWVK4Dsil/woKmsCpxClWfU/MzmQlhbdH+x8V2= SYO a4aJWiixx59DxQARAQABzSFBbmRyZWFzIEhlaWdsIDxhbmRyZWFzQGhlaWdsLm9yZz7CwY4EE= wEK ADgWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQDswIbAwULCQgHAwUVCgkICwUWAgMBAAIeA= QIX gAAKCRCo1UN+znJP5clsD/4vnmCp5oVIXdNXkK3PNajHR1ddpr2+Ake+bo6TS801MSd638f2U= g/e Qmu6j0XuHbgJql9wnoDh0Oq47bPxGTszPbbhD0FL1s6YBDqJKcz2okbmYRutumC52u4h8dGxb= VjC M9le1rckK54aDjkzL27iGRNfQLw1vg9gdl1yRz866bZ75MItk/7BewJrodQ5zweNcDVOmYseP= Lpo 13peB1mzDP/tuBH4CpoeDtAb/+Rc5Qv/J6P7iMDC4fPbFIl5//Ge7blMV98seXOAYMCvDYmLc= JFb nESBla/8te8lKE2E1PjwnIeMvDfYHn17CYd2UqnmlQbJbN30/Y2eiPT9w7wjrgc+qGRWEU+hu= GMl rDXQmmAtHPADf08QwOWpDVoZ+WFsQEB3f2fsZtfOnxXv8yb+Q16kVcPWaRyvusT5KLT39h2Vv= Zlh H8uporNimjs7+Rl8Fs7PP6n2L+OCnI1sSCTixBQT4MDNM6IVxqhy5j8M9ig3vR7czJgVVsDmK= CFi gOibvIFgxfRH2A7JjyplO034eUw7I3IJdffuBWjZ8SCfwZ3sS67UaPy01UVovSQKikEJBfADE= cl4 X25YsHvHXCksYLoZHb6wvtFzUrjxXwipwzlWtNBR2gTB2lCfeCLcwYcHdN8qcgg+emxDkBHeL= /Ml w5OLGW86dy6ha3BJDQgdL8LBcwQQAQoAHRYhBJZ8z6UN/+4Du4v18sqSE8db/ORyBQJcxBvDA= AoJ EMqSE8db/ORyHLUP/iADAMreqincMvKf8A0BMhAl79ZFhXkcFeEvb7KreVNp9pFBqUMtpvD6M= wY8 MpX+B9ys7qL8uY01Mf4ovex+O3tDmRRDMtho7Af2bO7Dyku7gnjtR0qdb+ceMDyVbmODVoMN+= Sh8 a9bj0uY0BlCsOkDb6hYyIf1xXAHkrX4wZbbjzpwNWoTQxsJo5ho7V/7CXMBYL6nLYpXR7vmgU= ori 2FbmiDIu+sKWbDezWcTNXItkn0WpIGTGSPWMLzEIJznOFJZlBd2q+/YHKqO/3G53tl62XLBjj= 9TC u1cnScsFJKhVRjn/mcwI9rrg4tLuSIfGqAoq29YSd832r9iC8CBuHc/T7MySekxNrdxnpecHy= Ajw AI+RhF1g+fVrmeYt1+4stwfpmLp+gEFPiHxoQkKc2q8pjNRmtoKvf2Z9cqauB+8QWyIKjgrab= dJy ev/b54o+CqxNo4KSjhwSBjb/ihVw1W2AWLkEGJUysHP6r1E12dXlYrEvBm13LIP+OOqpZRY5K= MKi WNjmQF3wtEr6SjMYXcLx+1ydVQLqFa6in57YotfNqlehiU1KDhJ/AyU+tgBJ3OxShS6p4Gmia= Dvh 8qDp0bm7GxkQEA+8kOmn+4mY5E5LzzlbIkHoDqqZs/RkWoxNpXyhIx6zqqlE4yASuWwY98tco= mx8 /CClg5DoQAl2NvWPwsFzBBABCgAdFiEEclTRxmnDsSbzEk7xbQJ8ZCRit3gFAlzEHMsACgkQb= QJ8 ZCRit3jsmA/+JJUt4Bg9cJ3itTdP+0PfSVYh0xwR+ev5b0sAj2moWowk1U0IEzHhM5eHlAJ/5= s4/ peG2Bkv2vCB+mTMFCbcuZfdsF1N13MSFqJH9ZLjZY5QGo9IqAF+JI1Tu0zArKOXWI+Fs4WXaY= lp2 f+aMccVrd6LIObbgKKQzH2n4u3nxwfVsWSZcNVCvIQVI9FPexH9C4EbPN/ocxx4/Qewx/ie+s= slL M8CVULcZmJeN+rcjWR4hr2l9zY925WpbQ/LE6cmnqDWVS+SgFQGF6j1nsUJzRA2pYk/Q12o+2= ka9 1/o9pPu3Z8gEFu7ljflT3iO4G139crRNXRE00qfBQft9VvMl02iGQlCbK1ZER8Rou5yDPjfBk= MHP DoSUa45ILQqsUB/3rKT08ApA80QkgCh+cTyhvVCrZJPKWjusRn8mX9FM+lotL9ZWID9/Q90FJ= hli XyPj8gmsoFh+37/AV+Wl2jcNbG1CIzX1cx2KJ+2AWciBlE0046ztGuaHzpqzjeyvwxUHYTDJh= 2+t DyRCt7lrRrZuMTBlHCQw1GlSSrlPw9l1CASXto0gxnFgCpulTBHJQVPUr0XbjmT52xbmRlv3y= 4CR MCp+/0ZKzXddKZTA6XyIHuumRuKW0L1rBIfqgbUB0icE7tM/+bkYZzMExhnILF05nIIQKN5Rq= 59p t+KxrjK2t13OwU0EXMQFSAEQAL++X487itN2+5NbNK0O2iUkG6OOCK8Uiep+KpWwsfwf8rz5U= FUx Tn2EBfiTRCd9NXEMeiptjp8zsRVN2MSEv77a+aiMahUyIbI+4PUX+Y2fZRIXx7kpTn4T817iw= 19m FrSQ6c/qI88JUvmMA/r9FYbUAh0vjZEPc+WUmPnZYCShnna0pDhiJe1b3pjoxPTNA2arBkGhm= m1x th/rKN80Saf77ZtxOpRx+wiwXAKG54B6Q9fVWUzT5pRzJFPl6UEt4WaWVA8kMkbjLcv8k3fJT= MK0 ZpxjTIDFIqqYxiJIKE5TbuMvN9ilx/grUhdQ+Nu5kOJlOUiFfeqTUi/hJOljtRsh3WxJhpEmV= u+w 7/PJpLPPys1Xa7Ax6DHr/nR5iNL1tDZEjrW6/Wav7AYX8OnlZF6irml7APAusOfv4XemZfUb/= qva /pQjbJpeVYmedFyGgC96yR55bRbzXI4CHMvApRFxyUekQp09h49MvTNJ0dV3Uj9+V+PMS05OY= BIs KbRv+C9QaoCiuUK83BSd0XFvR1KuO3FRY3Dtc5zrdWuGNa0tUYAd82Dnu/pR1wmdyYdbXEcQH= uW0 Vx5Dm6TDQ1ZLNEh2ZZRqWQ8Qrppb3n5lhbjyNiPO0upJlxYl3qo6mRXzuQMoZOeH50ZPyqmZu= d+Z kHfg/Sq8PRHNdlBhtIZ6/FBTABEBAAHCw6wEGAEKACAWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5= QUC XMQFSAIbAgJACRCo1UN+znJP5cF0IAQZAQoAHRYhBDh6O3rdFXWZPESSt+BX/kgit7ZFBQJcx= AVI AAoJEOBX/kgit7ZFM28QALr4HOTaNkpLZMxJAECLxFQg8Yzg9GdUE4l6Xqeea+Qz6Hv2fO0AV= 8VQ ug7h7mFoAQQwG0lK5yHa/RF3tcApVEXMyL19AamMNnA5H0mXEUcTvge2JeVK9ONTBYjSR6llO= nUK Co24p3lnzmp6eZNEfaTPbSGo7UTmWcqfHtkvH4C5hOhDyY6GTVrgcMV2G2B1jq4evn0XxdqTi= po3 VyAMtwW/HlTHKXpXpW0QhzD+D6ioNUgyQjpPjkI3BWJHzSCWVUKgWD2EdOu+IsciDM115APvd= yeX vgWNF8jphl+PJf2inqS8iSrd4pf04//tqNhkmBHSIFh6LwPlUUMEjKI4sWUYcL8zZimUmaK9H= yZe bZq+IQFnjMw80h4iMc4YpY8mKgz4ld7wNV68+NFpgn+YaK6EVCpML91ret5kR4PyhO3tlMydY= zW3 SFmmYFIEOEn+l5V223/8RDsg7XilBPZXtYDDpCJSedo3+d9eeBTyLnaXhnmhs1N06IVMbga/x= g6B YT0OxJ7KFhyLW9SQ2+22oVqtfqGR9+Qx8UaiLnAx2a0ZjCHOspg/RTsXz7jqC8Ez9AVEPLOrw= /It IFI8Mx1AoJxfdoK9JIIsSNHeKrvCNmRK1n7NnNLa1JDRXYNgxsCD81YJzpQjtUC4KBKbFevs/= MHD Ksg/o2mlfeNy3AAEYckW7aMP/AjhDWZuUB+WoPnVO3qoaRdtt4aMRI+8Vjwsci3HHcueQa7Xs= S/J fzg85MUXqN7PozrfEBgwk5Z+kdFW+4dhiaEXntEqWUgwkExJ5ysmP597WIQG2hUpX0jwkrzdZ= q6r Z/87mHCAMgFk1Lg/6oPOQqXvBdLFlMo6RIPawC8EeROcIuszvzKR4GIEIyXyR5rflLUUFfvLr= NPk MeuxA5CKoN1IidlngMO/sH58aac2Z67k7nrNQk62QeMFQndcKb45Pt3bgPjDSB98hlAklKzuH= kxx lwreilFcBqx/8f1qeg3tTkF29RkSaP38K9RnLhrfRrt4Tz8fKTF/C6A1HqL2dMQmto14S8U2o= zq9 3xiu0oUpLFdOoqfqPxgiqbqWUFIAY4JS4J2o9HXwjFii6X7/VJ9Yj0DNCrZytvSRR24j6p2r2= HFg fEPDs6NFPGoF9vNksJhc1FViEkjt1z5vTdmu3+DRSD3QTpRUujVnUL8jr0ggoZ3CI6qjVqb8K= 2+d dubT9SxWKNbBOcNOwGtqQtw2z8FZ/2tQOvu9A44A5gCYJ5fHj9uvcvEKJe6X7hX7WBpAItZUe= Y8x D91uNSY2/uceh0pE6APHxNMRaLCKMRpyvRCHqRbA2iiLT0qF4pmwYUtYIig1TkNczbtzj38mv= H+G OQ6onUMxyW18qrqJn8LzvlhkzsFNBFzEBbgBEACo/XIhTsNMVM1XLI2qzKWWLIIIYN/uTcoum= h0A eh98saWYjg68H/fv2CZhF0CZ7JXcW3EqCjWzLnHiGXTMumYwCm5vgxic1uHTS6tv97hNPNA80= vKK Fgs/ofYM4MtzQWdLw/c7lzF6qomhbr9woKbYgwRnp8qh2C84aH6+OQv6I1t2fWE7qhoLMrSh2= EiK xeogXkyNqKzlRibBUOsjurTXg+UJt7NEnrp/qgm1m9zhAkMoadFs5bROEb24qZ7eDij1HmrM6= mUb 4OkL2PnDzkUBJ2At5otp+uUCJrATS2tAz0OGNu3ijJP94+Y1d3Nt6jC5pAI40ZcxSXMMrLFAT= XJi NYLaD/Y6tpLgXaLQF1krgtvcGVkxJ8/fJVrKVcmF8Cfnab+rbNDIxLAwWT+dor2BwDgRoRI45= cyG XB7YHstdk9kBUZqff1BrMZLGEmp+M6xE2wFPWan4kD2oIh5B14CKUMYB+CBmMlJhkIzBl2GvO= 3Hv VyywCk2EourRxjDocZxyajE/fwFuAK5emuFKrucMmsnxzZMMJdkoJmnozsBS9Oj9e8YiR+yAM= Dex x4152G6SOCR9JSxnFUBPEKOgabIPLY3eQfn0nBdh/mr/iKSg+5zj3bsbvUetvRFdTbUTFnqss= L7b 3Q5ydaL3Q6PjCO/Fe0bmLKXnY2AzY8emb3xc/wARAQABwsF2BBgBCgAgFiEEWe7QZoa1zQB2l= HAN qNVDfs5yT+UFAlzEBbgCGwwACgkQqNVDfs5yT+XL9w//VJKq2qxGxS1IGSaaowcneiRx88ZfB= Tzk takhbqXhnWFwP9vuTaHcSzRowFIVzea55k/5mQeKuTTEt7k0Yb29lwoT+iqi12V/73EBIaUK+= JT5 ZP28bnQXkkqqpRzcro4lDzi5geamt7KMsWDmYqCHyXU2xXeALnqfLv1jfsJJMeoDzLl8ql50q= m1z +u94VOXf94dlqmV9v6QWoxww2k2xNWBAeUD2YzUXAZncpXbCK1MIRFBHmbg4HAapmpFUewPfs= O4P pUEJqG1IA6rl9csZnc97BvCCha6SZMvXGrEIi/ajNfD0mU2p3Iy5F1UXNx9yJlMziQvqUziA7= MSW olT2ZYr/unSrckXUh7lAwE4tq8RhhXZ2cjL+5ubk/xGFBJycn+YKoT5gmZ+gwGrluN0VJFogf= pY2 RJbF8j8VbUR+vGKxlusgyeC7uEFAoVsIUJFQ3QaPtGmnIZgP3KSz7HsZkAwiXHJ5P6wpH3CWM= u4J aOQlOMo0NPxRZOvtfAkdDb+i4jd+YjvuJkJlur1p6yhu/02cE7/BoDONgATHZqFmYzubWtCU9= Lrf q1RnVBVnH/hLM2IxMGyBYsNDRW3FwSZh7nj6vxjijS9KsxwNiAFzNl78BKlIkHgAjWVDejezm= ncB 5ixg8G0GzKxIBt3S5nrkQNz3HBJEuIwmP7HyMbLbG27OwU0EXMQF6wEQAMUl2EK3LUUh6uunJ= 55v s0z8D0XZFpgm6cwVJgaWw+1H/bXJQR56oosOf+WUM0x1jhBVTLhI+oOK+uz1VkeZRMvTRxYob= fNq n7V5Gn8D8tO8z55yuHgHxn8T8+ZV8RzEbITDNmnK3VNC+mGvWCOe03gU6rhaE9qb3fhFreQA1= e85 XR3WqwxR/m/Vxdc0ANxgrij+VEOZDzlknAt9s93sPQDCqCGfNtRaKgVi/xvZUWvrYSBb1v5d3= wit KlADmuqWCWtc9+PuBmjUIObGP7Zll1dQ6enrtQ943ZsUujXYsdrfuaf5m47u/1G1IzwznIJwl= ZUU M2RAHQkCu+yjnXjtW0/ZEYV0RV+xZ5Qf2CtSq2rS5jpPKbtqhkzclX6ziV2ycRypR/vtbo81U= dP1 cbwSlSlxwp65Y7D+uV1F/7vI+OjUqJpD8mHgdh9OOZCWI2zHTSaH2FqS4LaT6kJIcd0sLoRPV= C3E U2vQQIM5aMyYpFlacZgmAryldp8cHwvbtpR4R2GWlXAW3w/pz2B7BD+xiUHvu2cXgeRYWgvtA= 7kw monmnhJ0NiN6cB4GPjr0ivysDNvdnnvCQ2FNMrqUGMhAK1fFh3nJF5CgMGZSyricZvE8tl7nl= XN4 TUlhhNqhSKyqHL7b0WjPhAUBNZvf1hutnl72rDAMBhTjYbEkLAl2/I5RABEBAAHCwXYEGAEKA= CAW IQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQF6wIbIAAKCRCo1UN+znJP5d4OD/9YMP8rUtR43= z0v Y1UnqMyZH9I8mOIL12AqRhsroaFb8rs3QU+u5cZGf2QvP2uOF6wFzjQGelZLjgVmctBYzutzs= jzX Id0D+B3O2KJhquRXEZ5HQlvZ6/YY0KDzNcYk2Tghg/NqvGltJtJuHrysPIL/0csA91mVUFs25= iap RwLrZfizTEzyh8KCrsV8j+c7r/UTRNkwDbTuq+s7kAyLVEWMTlBRkXg9IsxyX1F+k6xjSKRGf= XnI cct2BEYDcwNxzcPDOHpwzNCH3DCGDmuOLQGspp40liJ1cY1B7a1t3kpNRUv2YDth+jHs58BmF= Nfx WrBwv8OYulI+ehtErPTmOt6eNBhMp5EvoQuT6YwnL+2UwnA1SdNseG1y6tmgeEl/1PeGuYnze= vgk olNUS+4jzyWMG5deRldsjlHxMJBdT5VQXlXP8xb8oHQAkeR3KtlNyrtCi4R62btnIoSF7W9NY= heG aXXa2rHTVi82pqIg6p/E35MVh7X5nXIVOlGM6YXrdKapL/tRNExAW0xfrtwSJfMoxNAqFcwyR= e+i f3/7YeeVW9uqs8gSzAqD9x7JAYI2eW3JW6N3bdiZxIJ7wuk67zaW5rh36h9FhRM9KONvWbzXD= KN2 qyGMI8nCoorTHcnGOw8TqLh9cni59kQ+lEw/6d/vglsWEWhDJdt9r3ZWpMJW9w=3D=3D =3DQgWh -----END PGP PUBLIC KEY BLOCK----- --------------D6C6A0814B94472EDB9059EA-- --5JRW4rOsjUnAPJYc1xZXZjEKT6bVLIu2P--
  116371
November 15, 2021 13:35 kontakt@beberlei.de (Benjamin Eberlei)
On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl <andreas@heigl.org> 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 ppv@gmail.com> > 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/0000-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:andreas@heigl.org N 50°22'59.5" E 08°23'58" | > | https://andreas.heigl.org | > +---------------------------------------------------------------------+ > | https://hei.gl/appointmentwithandreas | > +---------------------------------------------------------------------+ >
  116372
November 15, 2021 13:50 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl <andreas@heigl.org> 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 ppv@gmail.com> > 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
  116376
November 15, 2021 16:23 Andreas Heigl <andreas@heigl.org>
--PKkULfIY29BI0AsH2p7SJWVRQn0ITCASB
Content-Type: multipart/mixed;
 boundary="------------EB6755401F49E7695936DE0D"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------EB6755401F49E7695936DE0D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hey Nikita.

On 15.11.21 14:50, Nikita Popov wrote:
> [...] > I hope that the new "Motivation" section clarifies things a bit, especi= ally
> in regards to why "static analysis" is only a partial solution to this > problem: https://wiki.php.net/rfc/deprecate_dynamic_properties#motivati= on
Thanks for the clarification! One thing, that can verify the correct working of properties, whether=20 that is dynamic or static ones, is testing. So when one wants to make=20 sure that their code behaves as it should, then proper testing can help=20 with that. So while the static analysis is one possibility, the other=20 one is writing appropriate tests. While that will still not eliminate=20 the usage of external tools it is fore sure something that most of the=20 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=20 appreciate. And using an Annotation for that is great. What I am still=20 missing is the differentiation between "everything is strict and you=20 have to explicitly opt-in to make it dynamic" and an "everything is=20 dynamic and you can use a marker to mark this explicitly an intended=20 behaviour". That would allow users to mark a class explicitly to use=20 dynamic features even though it would make no difference code-wise. And that could already be implemented via a userland-shim right now=20 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=20 reduction of the object-size by 8 byte. Is there a comparison of how=20 much that would be in percent for some default applications? So is that=20 something that actually "pays off"? Thanks again for your insights! Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --------------EB6755401F49E7695936DE0D Content-Type: application/pgp-keys; name="OpenPGP_0xA8D5437ECE724FE5.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xA8D5437ECE724FE5.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFzEA7MBEACpvo0AbmZG6lUGMvDUebQcYVjOPrdqtnlb2WoZH9FrJyHyenzejO29VCjue= kdh u44sUNgEHXxExUekguLDGZOzC9926g2rGDWO3MU1oqRlKURnOWsp/i0d9WM07ihj/lL6smT9Y= Lea gtPCJporUiFW8JyIusBWWhlL8hp8ZDvEfmvi06xDXML3wXzH/KWmoew3LgdwCZPkQSIWemUDP= ZKc UL8eeVkhYIJA9VKQnGSx36p5T7Ch/l+iqiPlyY1GUNItX9AQjpr07V0kIjyK+yHn6Aw1uy1xW= rLn 7ATDX8YuMvaz72+c/P2zQReMWoZNfggd2FHOPRUHvHcC9C91PuzJh8e9hvtU/szDrPvvCVpg5= aRy mN/YPFJBSEqZfDelhD+8A1TJNPqSyzc21Qdd61636ynryawIW+HxFT/UN1eA7V5/fdjeRyNUJ= d7B 99Vo5A/lI25bIpg6cPLOLpVPFHEpNlGPQ8pcMRwnjG9GR74PTfH7Dy8Ksq8lpygPljJInZbz0= 870 cHlM5XSdIPTXWQFfJi0e2kfaLCEni/Vih+eL0e5F7X3RtaXY0HRFYHX8dY7ojf3sZJjdPVm3A= QXY 1yNkjnRxyJ/4gIwdFwYplU6lRBL92jdDLavPWVK4Dsil/woKmsCpxClWfU/MzmQlhbdH+x8V2= SYO a4aJWiixx59DxQARAQABzSFBbmRyZWFzIEhlaWdsIDxhbmRyZWFzQGhlaWdsLm9yZz7CwY4EE= wEK ADgWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQDswIbAwULCQgHAwUVCgkICwUWAgMBAAIeA= QIX gAAKCRCo1UN+znJP5clsD/4vnmCp5oVIXdNXkK3PNajHR1ddpr2+Ake+bo6TS801MSd638f2U= g/e Qmu6j0XuHbgJql9wnoDh0Oq47bPxGTszPbbhD0FL1s6YBDqJKcz2okbmYRutumC52u4h8dGxb= VjC M9le1rckK54aDjkzL27iGRNfQLw1vg9gdl1yRz866bZ75MItk/7BewJrodQ5zweNcDVOmYseP= Lpo 13peB1mzDP/tuBH4CpoeDtAb/+Rc5Qv/J6P7iMDC4fPbFIl5//Ge7blMV98seXOAYMCvDYmLc= JFb nESBla/8te8lKE2E1PjwnIeMvDfYHn17CYd2UqnmlQbJbN30/Y2eiPT9w7wjrgc+qGRWEU+hu= GMl rDXQmmAtHPADf08QwOWpDVoZ+WFsQEB3f2fsZtfOnxXv8yb+Q16kVcPWaRyvusT5KLT39h2Vv= Zlh H8uporNimjs7+Rl8Fs7PP6n2L+OCnI1sSCTixBQT4MDNM6IVxqhy5j8M9ig3vR7czJgVVsDmK= CFi gOibvIFgxfRH2A7JjyplO034eUw7I3IJdffuBWjZ8SCfwZ3sS67UaPy01UVovSQKikEJBfADE= cl4 X25YsHvHXCksYLoZHb6wvtFzUrjxXwipwzlWtNBR2gTB2lCfeCLcwYcHdN8qcgg+emxDkBHeL= /Ml w5OLGW86dy6ha3BJDQgdL8LBcwQQAQoAHRYhBJZ8z6UN/+4Du4v18sqSE8db/ORyBQJcxBvDA= AoJ EMqSE8db/ORyHLUP/iADAMreqincMvKf8A0BMhAl79ZFhXkcFeEvb7KreVNp9pFBqUMtpvD6M= wY8 MpX+B9ys7qL8uY01Mf4ovex+O3tDmRRDMtho7Af2bO7Dyku7gnjtR0qdb+ceMDyVbmODVoMN+= Sh8 a9bj0uY0BlCsOkDb6hYyIf1xXAHkrX4wZbbjzpwNWoTQxsJo5ho7V/7CXMBYL6nLYpXR7vmgU= ori 2FbmiDIu+sKWbDezWcTNXItkn0WpIGTGSPWMLzEIJznOFJZlBd2q+/YHKqO/3G53tl62XLBjj= 9TC u1cnScsFJKhVRjn/mcwI9rrg4tLuSIfGqAoq29YSd832r9iC8CBuHc/T7MySekxNrdxnpecHy= Ajw AI+RhF1g+fVrmeYt1+4stwfpmLp+gEFPiHxoQkKc2q8pjNRmtoKvf2Z9cqauB+8QWyIKjgrab= dJy ev/b54o+CqxNo4KSjhwSBjb/ihVw1W2AWLkEGJUysHP6r1E12dXlYrEvBm13LIP+OOqpZRY5K= MKi WNjmQF3wtEr6SjMYXcLx+1ydVQLqFa6in57YotfNqlehiU1KDhJ/AyU+tgBJ3OxShS6p4Gmia= Dvh 8qDp0bm7GxkQEA+8kOmn+4mY5E5LzzlbIkHoDqqZs/RkWoxNpXyhIx6zqqlE4yASuWwY98tco= mx8 /CClg5DoQAl2NvWPwsFzBBABCgAdFiEEclTRxmnDsSbzEk7xbQJ8ZCRit3gFAlzEHMsACgkQb= QJ8 ZCRit3jsmA/+JJUt4Bg9cJ3itTdP+0PfSVYh0xwR+ev5b0sAj2moWowk1U0IEzHhM5eHlAJ/5= s4/ peG2Bkv2vCB+mTMFCbcuZfdsF1N13MSFqJH9ZLjZY5QGo9IqAF+JI1Tu0zArKOXWI+Fs4WXaY= lp2 f+aMccVrd6LIObbgKKQzH2n4u3nxwfVsWSZcNVCvIQVI9FPexH9C4EbPN/ocxx4/Qewx/ie+s= slL M8CVULcZmJeN+rcjWR4hr2l9zY925WpbQ/LE6cmnqDWVS+SgFQGF6j1nsUJzRA2pYk/Q12o+2= ka9 1/o9pPu3Z8gEFu7ljflT3iO4G139crRNXRE00qfBQft9VvMl02iGQlCbK1ZER8Rou5yDPjfBk= MHP DoSUa45ILQqsUB/3rKT08ApA80QkgCh+cTyhvVCrZJPKWjusRn8mX9FM+lotL9ZWID9/Q90FJ= hli XyPj8gmsoFh+37/AV+Wl2jcNbG1CIzX1cx2KJ+2AWciBlE0046ztGuaHzpqzjeyvwxUHYTDJh= 2+t DyRCt7lrRrZuMTBlHCQw1GlSSrlPw9l1CASXto0gxnFgCpulTBHJQVPUr0XbjmT52xbmRlv3y= 4CR MCp+/0ZKzXddKZTA6XyIHuumRuKW0L1rBIfqgbUB0icE7tM/+bkYZzMExhnILF05nIIQKN5Rq= 59p t+KxrjK2t13OwU0EXMQFSAEQAL++X487itN2+5NbNK0O2iUkG6OOCK8Uiep+KpWwsfwf8rz5U= FUx Tn2EBfiTRCd9NXEMeiptjp8zsRVN2MSEv77a+aiMahUyIbI+4PUX+Y2fZRIXx7kpTn4T817iw= 19m FrSQ6c/qI88JUvmMA/r9FYbUAh0vjZEPc+WUmPnZYCShnna0pDhiJe1b3pjoxPTNA2arBkGhm= m1x th/rKN80Saf77ZtxOpRx+wiwXAKG54B6Q9fVWUzT5pRzJFPl6UEt4WaWVA8kMkbjLcv8k3fJT= MK0 ZpxjTIDFIqqYxiJIKE5TbuMvN9ilx/grUhdQ+Nu5kOJlOUiFfeqTUi/hJOljtRsh3WxJhpEmV= u+w 7/PJpLPPys1Xa7Ax6DHr/nR5iNL1tDZEjrW6/Wav7AYX8OnlZF6irml7APAusOfv4XemZfUb/= qva /pQjbJpeVYmedFyGgC96yR55bRbzXI4CHMvApRFxyUekQp09h49MvTNJ0dV3Uj9+V+PMS05OY= BIs KbRv+C9QaoCiuUK83BSd0XFvR1KuO3FRY3Dtc5zrdWuGNa0tUYAd82Dnu/pR1wmdyYdbXEcQH= uW0 Vx5Dm6TDQ1ZLNEh2ZZRqWQ8Qrppb3n5lhbjyNiPO0upJlxYl3qo6mRXzuQMoZOeH50ZPyqmZu= d+Z kHfg/Sq8PRHNdlBhtIZ6/FBTABEBAAHCw6wEGAEKACAWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5= QUC XMQFSAIbAgJACRCo1UN+znJP5cF0IAQZAQoAHRYhBDh6O3rdFXWZPESSt+BX/kgit7ZFBQJcx= AVI AAoJEOBX/kgit7ZFM28QALr4HOTaNkpLZMxJAECLxFQg8Yzg9GdUE4l6Xqeea+Qz6Hv2fO0AV= 8VQ ug7h7mFoAQQwG0lK5yHa/RF3tcApVEXMyL19AamMNnA5H0mXEUcTvge2JeVK9ONTBYjSR6llO= nUK Co24p3lnzmp6eZNEfaTPbSGo7UTmWcqfHtkvH4C5hOhDyY6GTVrgcMV2G2B1jq4evn0XxdqTi= po3 VyAMtwW/HlTHKXpXpW0QhzD+D6ioNUgyQjpPjkI3BWJHzSCWVUKgWD2EdOu+IsciDM115APvd= yeX vgWNF8jphl+PJf2inqS8iSrd4pf04//tqNhkmBHSIFh6LwPlUUMEjKI4sWUYcL8zZimUmaK9H= yZe bZq+IQFnjMw80h4iMc4YpY8mKgz4ld7wNV68+NFpgn+YaK6EVCpML91ret5kR4PyhO3tlMydY= zW3 SFmmYFIEOEn+l5V223/8RDsg7XilBPZXtYDDpCJSedo3+d9eeBTyLnaXhnmhs1N06IVMbga/x= g6B YT0OxJ7KFhyLW9SQ2+22oVqtfqGR9+Qx8UaiLnAx2a0ZjCHOspg/RTsXz7jqC8Ez9AVEPLOrw= /It IFI8Mx1AoJxfdoK9JIIsSNHeKrvCNmRK1n7NnNLa1JDRXYNgxsCD81YJzpQjtUC4KBKbFevs/= MHD Ksg/o2mlfeNy3AAEYckW7aMP/AjhDWZuUB+WoPnVO3qoaRdtt4aMRI+8Vjwsci3HHcueQa7Xs= S/J fzg85MUXqN7PozrfEBgwk5Z+kdFW+4dhiaEXntEqWUgwkExJ5ysmP597WIQG2hUpX0jwkrzdZ= q6r Z/87mHCAMgFk1Lg/6oPOQqXvBdLFlMo6RIPawC8EeROcIuszvzKR4GIEIyXyR5rflLUUFfvLr= NPk MeuxA5CKoN1IidlngMO/sH58aac2Z67k7nrNQk62QeMFQndcKb45Pt3bgPjDSB98hlAklKzuH= kxx lwreilFcBqx/8f1qeg3tTkF29RkSaP38K9RnLhrfRrt4Tz8fKTF/C6A1HqL2dMQmto14S8U2o= zq9 3xiu0oUpLFdOoqfqPxgiqbqWUFIAY4JS4J2o9HXwjFii6X7/VJ9Yj0DNCrZytvSRR24j6p2r2= HFg fEPDs6NFPGoF9vNksJhc1FViEkjt1z5vTdmu3+DRSD3QTpRUujVnUL8jr0ggoZ3CI6qjVqb8K= 2+d dubT9SxWKNbBOcNOwGtqQtw2z8FZ/2tQOvu9A44A5gCYJ5fHj9uvcvEKJe6X7hX7WBpAItZUe= Y8x D91uNSY2/uceh0pE6APHxNMRaLCKMRpyvRCHqRbA2iiLT0qF4pmwYUtYIig1TkNczbtzj38mv= H+G OQ6onUMxyW18qrqJn8LzvlhkzsFNBFzEBbgBEACo/XIhTsNMVM1XLI2qzKWWLIIIYN/uTcoum= h0A eh98saWYjg68H/fv2CZhF0CZ7JXcW3EqCjWzLnHiGXTMumYwCm5vgxic1uHTS6tv97hNPNA80= vKK Fgs/ofYM4MtzQWdLw/c7lzF6qomhbr9woKbYgwRnp8qh2C84aH6+OQv6I1t2fWE7qhoLMrSh2= EiK xeogXkyNqKzlRibBUOsjurTXg+UJt7NEnrp/qgm1m9zhAkMoadFs5bROEb24qZ7eDij1HmrM6= mUb 4OkL2PnDzkUBJ2At5otp+uUCJrATS2tAz0OGNu3ijJP94+Y1d3Nt6jC5pAI40ZcxSXMMrLFAT= XJi NYLaD/Y6tpLgXaLQF1krgtvcGVkxJ8/fJVrKVcmF8Cfnab+rbNDIxLAwWT+dor2BwDgRoRI45= cyG XB7YHstdk9kBUZqff1BrMZLGEmp+M6xE2wFPWan4kD2oIh5B14CKUMYB+CBmMlJhkIzBl2GvO= 3Hv VyywCk2EourRxjDocZxyajE/fwFuAK5emuFKrucMmsnxzZMMJdkoJmnozsBS9Oj9e8YiR+yAM= Dex x4152G6SOCR9JSxnFUBPEKOgabIPLY3eQfn0nBdh/mr/iKSg+5zj3bsbvUetvRFdTbUTFnqss= L7b 3Q5ydaL3Q6PjCO/Fe0bmLKXnY2AzY8emb3xc/wARAQABwsF2BBgBCgAgFiEEWe7QZoa1zQB2l= HAN qNVDfs5yT+UFAlzEBbgCGwwACgkQqNVDfs5yT+XL9w//VJKq2qxGxS1IGSaaowcneiRx88ZfB= Tzk takhbqXhnWFwP9vuTaHcSzRowFIVzea55k/5mQeKuTTEt7k0Yb29lwoT+iqi12V/73EBIaUK+= JT5 ZP28bnQXkkqqpRzcro4lDzi5geamt7KMsWDmYqCHyXU2xXeALnqfLv1jfsJJMeoDzLl8ql50q= m1z +u94VOXf94dlqmV9v6QWoxww2k2xNWBAeUD2YzUXAZncpXbCK1MIRFBHmbg4HAapmpFUewPfs= O4P pUEJqG1IA6rl9csZnc97BvCCha6SZMvXGrEIi/ajNfD0mU2p3Iy5F1UXNx9yJlMziQvqUziA7= MSW olT2ZYr/unSrckXUh7lAwE4tq8RhhXZ2cjL+5ubk/xGFBJycn+YKoT5gmZ+gwGrluN0VJFogf= pY2 RJbF8j8VbUR+vGKxlusgyeC7uEFAoVsIUJFQ3QaPtGmnIZgP3KSz7HsZkAwiXHJ5P6wpH3CWM= u4J aOQlOMo0NPxRZOvtfAkdDb+i4jd+YjvuJkJlur1p6yhu/02cE7/BoDONgATHZqFmYzubWtCU9= Lrf q1RnVBVnH/hLM2IxMGyBYsNDRW3FwSZh7nj6vxjijS9KsxwNiAFzNl78BKlIkHgAjWVDejezm= ncB 5ixg8G0GzKxIBt3S5nrkQNz3HBJEuIwmP7HyMbLbG27OwU0EXMQF6wEQAMUl2EK3LUUh6uunJ= 55v s0z8D0XZFpgm6cwVJgaWw+1H/bXJQR56oosOf+WUM0x1jhBVTLhI+oOK+uz1VkeZRMvTRxYob= fNq n7V5Gn8D8tO8z55yuHgHxn8T8+ZV8RzEbITDNmnK3VNC+mGvWCOe03gU6rhaE9qb3fhFreQA1= e85 XR3WqwxR/m/Vxdc0ANxgrij+VEOZDzlknAt9s93sPQDCqCGfNtRaKgVi/xvZUWvrYSBb1v5d3= wit KlADmuqWCWtc9+PuBmjUIObGP7Zll1dQ6enrtQ943ZsUujXYsdrfuaf5m47u/1G1IzwznIJwl= ZUU M2RAHQkCu+yjnXjtW0/ZEYV0RV+xZ5Qf2CtSq2rS5jpPKbtqhkzclX6ziV2ycRypR/vtbo81U= dP1 cbwSlSlxwp65Y7D+uV1F/7vI+OjUqJpD8mHgdh9OOZCWI2zHTSaH2FqS4LaT6kJIcd0sLoRPV= C3E U2vQQIM5aMyYpFlacZgmAryldp8cHwvbtpR4R2GWlXAW3w/pz2B7BD+xiUHvu2cXgeRYWgvtA= 7kw monmnhJ0NiN6cB4GPjr0ivysDNvdnnvCQ2FNMrqUGMhAK1fFh3nJF5CgMGZSyricZvE8tl7nl= XN4 TUlhhNqhSKyqHL7b0WjPhAUBNZvf1hutnl72rDAMBhTjYbEkLAl2/I5RABEBAAHCwXYEGAEKA= CAW IQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQF6wIbIAAKCRCo1UN+znJP5d4OD/9YMP8rUtR43= z0v Y1UnqMyZH9I8mOIL12AqRhsroaFb8rs3QU+u5cZGf2QvP2uOF6wFzjQGelZLjgVmctBYzutzs= jzX Id0D+B3O2KJhquRXEZ5HQlvZ6/YY0KDzNcYk2Tghg/NqvGltJtJuHrysPIL/0csA91mVUFs25= iap RwLrZfizTEzyh8KCrsV8j+c7r/UTRNkwDbTuq+s7kAyLVEWMTlBRkXg9IsxyX1F+k6xjSKRGf= XnI cct2BEYDcwNxzcPDOHpwzNCH3DCGDmuOLQGspp40liJ1cY1B7a1t3kpNRUv2YDth+jHs58BmF= Nfx WrBwv8OYulI+ehtErPTmOt6eNBhMp5EvoQuT6YwnL+2UwnA1SdNseG1y6tmgeEl/1PeGuYnze= vgk olNUS+4jzyWMG5deRldsjlHxMJBdT5VQXlXP8xb8oHQAkeR3KtlNyrtCi4R62btnIoSF7W9NY= heG aXXa2rHTVi82pqIg6p/E35MVh7X5nXIVOlGM6YXrdKapL/tRNExAW0xfrtwSJfMoxNAqFcwyR= e+i f3/7YeeVW9uqs8gSzAqD9x7JAYI2eW3JW6N3bdiZxIJ7wuk67zaW5rh36h9FhRM9KONvWbzXD= KN2 qyGMI8nCoorTHcnGOw8TqLh9cni59kQ+lEw/6d/vglsWEWhDJdt9r3ZWpMJW9w=3D=3D =3DQgWh -----END PGP PUBLIC KEY BLOCK----- --------------EB6755401F49E7695936DE0D-- --PKkULfIY29BI0AsH2p7SJWVRQn0ITCASB--
  116377
November 15, 2021 16:52 rowan.collins@gmail.com (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]
  116382
November 15, 2021 17:20 larry@garfieldtech.com ("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
  116427
November 16, 2021 22:10 pollita@php.net (Sara Golemon)
On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield <larry@garfieldtech.com>
wrote:

> 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. >
This is exactly what Nikita is proposing, except that instead of the attribute being introduced in PHP 8.2, he's proposing to introduce it EARLIER. Roughly PHP 2 sort of timeframe. This is because attributes are forward compatible by design and developers can already start adding #[AllowDynamicProperties] to their code NOW. Even their code that was written to run cleanly on PHP 5.6 because users are terrible at upgrading their servers despite a 2x performance increase. The point is, we don't need 8.2 to be a soft-launch before deprecation because precisely nobody is prevented from adding this attribute preemptively. -Sara
  116431
November 16, 2021 23:55 larry@garfieldtech.com ("Larry Garfield")
On Tue, Nov 16, 2021, at 4:10 PM, Sara Golemon wrote:
> On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield <larry@garfieldtech.com> > wrote: > >> 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. >> > > This is exactly what Nikita is proposing, except that instead of the > attribute being introduced in PHP 8.2, he's proposing to introduce it > EARLIER. Roughly PHP 2 sort of timeframe. > > This is because attributes are forward compatible by design and developers > can already start adding #[AllowDynamicProperties] to their code NOW. Even > their code that was written to run cleanly on PHP 5.6 because users are > terrible at upgrading their servers despite a 2x performance increase. > > > The point is, we don't need 8.2 to be a soft-launch before deprecation > because precisely nobody is prevented from adding this attribute > preemptively. > > -Sara
It's not *quite* the same, although your point about preemptive attributes is valid. 1. If we adopt the RFC right now as-is, the market has ~12 months to add the attribute. If we instead have a default-true flag that changes to default false in the future, it means at minimum 24 months in which to add the attribute to opt-in to dynamic properties. 2. The RFC as-is has no way for developers to opt-in to actively rejecting dynamic properties. They'll get a deprecation, but... we're shouting from the rooftops that deprecations shouldn't be a big red warning, so if you want a big red warning you can't get that until PHP 9. With the flag attribute, developers could opt into "please slap me across the face if I use dynamic properties by accident" in ~12 months when 8.2 ships, rather than waiting 36-48 months until the likely PHP 9 release. So it gives the nitpickers what they want sooner, and gives the old-codies more time to get their ducks in a row. --Larry Garfield
  116433
November 17, 2021 00:45 claude.pache@gmail.com (Claude Pache)
> Le 17 nov. 2021 à 00:56, Larry Garfield <larry@garfieldtech.com> a écrit : > > They'll get a deprecation, but... we're shouting from the rooftops that deprecations shouldn't be a big red warning, so if you want a big red warning you can't get that until PHP 9.
Deprecation notices *are* big red warnings. They mean: the feature *will* be removed or altered in the next major version. The beauty of deprecation notices is that they warn you about future breakage without actually breaking anything. There is no need to invent some new sophisticated way, but only to learn to use correctly the existing one. —Claude
  116434
November 17, 2021 01:12 pollita@php.net (Sara Golemon)
On Tue, Nov 16, 2021 at 5:55 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> 1. If we adopt the RFC right now as-is, the market has ~12 months to add > the attribute. If we instead have a default-true flag that changes to > default false in the future, it means at minimum 24 months in which to add > the attribute to opt-in to dynamic properties. > > Okay sure, but that's an argument about lead time, not about
implementation. If we agree on targeting 9.0 for this becoming an error (and I think we do), then the argument that's left is whether users get notified as early as 8.2, or if they only get notified as of 8.3. Personally, I want to give users MORE lead time, but having the deprecation warnings come up sooner, rather than later. Assuming 9.0 comes out in late 2025 (guesstimate based on the cadence of 7.x), then including the deprecation with 8.2 (released in late 2022) will give users three years to attach an attribute where needed. If we delay the deprecation notice until 8.3 (released in late 2023), then they only have two years. I know this is the opposite end of lead time than you're talking about (you want max lead time before a deprecation notice even shows up), and here's why you're wrong: Most users don't pay attention to internals. That extra year you give them until notices show up will be wasted in ignorance as they don't know they have any work to do at all. All you will have done is robbed them of a year to implement the escape hatch (though let's be honest, they don't even need ONE year to do it). The only developers paying attention to internals@ traffic are the ones who have literally already added this attribute to their code bases in anticipation of this change.
> 2. The RFC as-is has no way for developers to opt-in to actively rejecting > dynamic properties. They'll get a deprecation, but... we're shouting from > the rooftops that deprecations shouldn't be a big red warning, so if you > want a big red warning you can't get that until PHP 9. With the flag > attribute, developers could opt into "please slap me across the face if I > use dynamic properties by accident" in ~12 months when 8.2 ships, rather > than waiting 36-48 months until the likely PHP 9 release. > > Your premise is that, since deprecation warnings will be ignored, we should
increase the verbosity level of the warning, but only for people who clearly know that a problem exists and can opt in to it? I'm sorry, but I don't track the logic of that. -Sara
  116381
November 15, 2021 17:20 Andreas Heigl <andreas@heigl.org>
--NQeyRYDzHIEGLBG9C99gmkWOk9k2GlzQ7
Content-Type: multipart/mixed;
 boundary="------------349AB84A6DD4E821B5C3754B"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------349AB84A6DD4E821B5C3754B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

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. >=20 >=20 > Can it? I can't actually see how that would work, without also having a= =20
> way to detect when dynamic properties were accessed, which brings us=20 > full circle. Also:
When you are testing whether writing 'X' to a property and then reading=20 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=20 in the setter and getter (or however you set and got the value).=20 Nevertheless you should be able to figure out whether you accidentally=20 misstyped a property name somewhere as that should break the test=20 (unless you misstyped the name twice). ANd whether you are doing the=20 assignement to a static property or to a dynamic one should be=20 irrelevant, the reading and the writing process are the same. Yes: That rips off a completely different topic: Testing "getters" and=20 "setters".
>=20 >> So the mistakes-part would be easy to handle.=20 >=20 > If you are working with a million lines of code going back 20 years,=20 > "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=20 is exactly to be able to leave existing code as it is. Otherwise the=20 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=20 accidentally to the wrong property. Which is what this RFC is all about. = Make sure that dynamic properties are not accidentally used.
>=20 > "Logging all deprecations and warnings on a production workload",=20 > however, *is* easy to handle. Diagnostic messages in logs are the *only= *=20
> way this behaviour will be spotted in old code.
That is absolutely correct. The main question is: "Do we *need* to spot=20 this behaviour in old code"? Not "Do we *want* to spot this behaviour in = old code".
>=20 >=20 >> 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=20 >> "everything is dynamic and you can use a marker to mark this=20 >> explicitly an intended behaviour". That would allow users to mark a=20 >> class explicitly to use dynamic features even though it would make no =
>> difference code-wise. >=20 >=20 > 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=20
good, why should we force it? And espechialy why do we need to force=20 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=20 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=20 (not a warning as that is too severe!). That way the behaviour can come=20 up in log files. Perhaps a new Level of notice like a=20 "bad_coding_practice". Or we use different "lanes" of reporting. One for = notices, errors, warnings et al and one for deprecations and such=20 asignment-oddities. When that has been done (should so far all be BC) and code-maintainers=20 have had enough time to modify their codebase (definition of "enough=20 time" is here clearly the main topic and needs discussion with=20 maintainers!) then we can talk about possibly phasing out the feature. My 0.02=E2=82=AC Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --------------349AB84A6DD4E821B5C3754B Content-Type: application/pgp-keys; name="OpenPGP_0xA8D5437ECE724FE5.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xA8D5437ECE724FE5.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFzEA7MBEACpvo0AbmZG6lUGMvDUebQcYVjOPrdqtnlb2WoZH9FrJyHyenzejO29VCjue= kdh u44sUNgEHXxExUekguLDGZOzC9926g2rGDWO3MU1oqRlKURnOWsp/i0d9WM07ihj/lL6smT9Y= Lea gtPCJporUiFW8JyIusBWWhlL8hp8ZDvEfmvi06xDXML3wXzH/KWmoew3LgdwCZPkQSIWemUDP= ZKc UL8eeVkhYIJA9VKQnGSx36p5T7Ch/l+iqiPlyY1GUNItX9AQjpr07V0kIjyK+yHn6Aw1uy1xW= rLn 7ATDX8YuMvaz72+c/P2zQReMWoZNfggd2FHOPRUHvHcC9C91PuzJh8e9hvtU/szDrPvvCVpg5= aRy mN/YPFJBSEqZfDelhD+8A1TJNPqSyzc21Qdd61636ynryawIW+HxFT/UN1eA7V5/fdjeRyNUJ= d7B 99Vo5A/lI25bIpg6cPLOLpVPFHEpNlGPQ8pcMRwnjG9GR74PTfH7Dy8Ksq8lpygPljJInZbz0= 870 cHlM5XSdIPTXWQFfJi0e2kfaLCEni/Vih+eL0e5F7X3RtaXY0HRFYHX8dY7ojf3sZJjdPVm3A= QXY 1yNkjnRxyJ/4gIwdFwYplU6lRBL92jdDLavPWVK4Dsil/woKmsCpxClWfU/MzmQlhbdH+x8V2= SYO a4aJWiixx59DxQARAQABzSFBbmRyZWFzIEhlaWdsIDxhbmRyZWFzQGhlaWdsLm9yZz7CwY4EE= wEK ADgWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQDswIbAwULCQgHAwUVCgkICwUWAgMBAAIeA= QIX gAAKCRCo1UN+znJP5clsD/4vnmCp5oVIXdNXkK3PNajHR1ddpr2+Ake+bo6TS801MSd638f2U= g/e Qmu6j0XuHbgJql9wnoDh0Oq47bPxGTszPbbhD0FL1s6YBDqJKcz2okbmYRutumC52u4h8dGxb= VjC M9le1rckK54aDjkzL27iGRNfQLw1vg9gdl1yRz866bZ75MItk/7BewJrodQ5zweNcDVOmYseP= Lpo 13peB1mzDP/tuBH4CpoeDtAb/+Rc5Qv/J6P7iMDC4fPbFIl5//Ge7blMV98seXOAYMCvDYmLc= JFb nESBla/8te8lKE2E1PjwnIeMvDfYHn17CYd2UqnmlQbJbN30/Y2eiPT9w7wjrgc+qGRWEU+hu= GMl rDXQmmAtHPADf08QwOWpDVoZ+WFsQEB3f2fsZtfOnxXv8yb+Q16kVcPWaRyvusT5KLT39h2Vv= Zlh H8uporNimjs7+Rl8Fs7PP6n2L+OCnI1sSCTixBQT4MDNM6IVxqhy5j8M9ig3vR7czJgVVsDmK= CFi gOibvIFgxfRH2A7JjyplO034eUw7I3IJdffuBWjZ8SCfwZ3sS67UaPy01UVovSQKikEJBfADE= cl4 X25YsHvHXCksYLoZHb6wvtFzUrjxXwipwzlWtNBR2gTB2lCfeCLcwYcHdN8qcgg+emxDkBHeL= /Ml w5OLGW86dy6ha3BJDQgdL8LBcwQQAQoAHRYhBJZ8z6UN/+4Du4v18sqSE8db/ORyBQJcxBvDA= AoJ EMqSE8db/ORyHLUP/iADAMreqincMvKf8A0BMhAl79ZFhXkcFeEvb7KreVNp9pFBqUMtpvD6M= wY8 MpX+B9ys7qL8uY01Mf4ovex+O3tDmRRDMtho7Af2bO7Dyku7gnjtR0qdb+ceMDyVbmODVoMN+= Sh8 a9bj0uY0BlCsOkDb6hYyIf1xXAHkrX4wZbbjzpwNWoTQxsJo5ho7V/7CXMBYL6nLYpXR7vmgU= ori 2FbmiDIu+sKWbDezWcTNXItkn0WpIGTGSPWMLzEIJznOFJZlBd2q+/YHKqO/3G53tl62XLBjj= 9TC u1cnScsFJKhVRjn/mcwI9rrg4tLuSIfGqAoq29YSd832r9iC8CBuHc/T7MySekxNrdxnpecHy= Ajw AI+RhF1g+fVrmeYt1+4stwfpmLp+gEFPiHxoQkKc2q8pjNRmtoKvf2Z9cqauB+8QWyIKjgrab= dJy ev/b54o+CqxNo4KSjhwSBjb/ihVw1W2AWLkEGJUysHP6r1E12dXlYrEvBm13LIP+OOqpZRY5K= MKi WNjmQF3wtEr6SjMYXcLx+1ydVQLqFa6in57YotfNqlehiU1KDhJ/AyU+tgBJ3OxShS6p4Gmia= Dvh 8qDp0bm7GxkQEA+8kOmn+4mY5E5LzzlbIkHoDqqZs/RkWoxNpXyhIx6zqqlE4yASuWwY98tco= mx8 /CClg5DoQAl2NvWPwsFzBBABCgAdFiEEclTRxmnDsSbzEk7xbQJ8ZCRit3gFAlzEHMsACgkQb= QJ8 ZCRit3jsmA/+JJUt4Bg9cJ3itTdP+0PfSVYh0xwR+ev5b0sAj2moWowk1U0IEzHhM5eHlAJ/5= s4/ peG2Bkv2vCB+mTMFCbcuZfdsF1N13MSFqJH9ZLjZY5QGo9IqAF+JI1Tu0zArKOXWI+Fs4WXaY= lp2 f+aMccVrd6LIObbgKKQzH2n4u3nxwfVsWSZcNVCvIQVI9FPexH9C4EbPN/ocxx4/Qewx/ie+s= slL M8CVULcZmJeN+rcjWR4hr2l9zY925WpbQ/LE6cmnqDWVS+SgFQGF6j1nsUJzRA2pYk/Q12o+2= ka9 1/o9pPu3Z8gEFu7ljflT3iO4G139crRNXRE00qfBQft9VvMl02iGQlCbK1ZER8Rou5yDPjfBk= MHP DoSUa45ILQqsUB/3rKT08ApA80QkgCh+cTyhvVCrZJPKWjusRn8mX9FM+lotL9ZWID9/Q90FJ= hli XyPj8gmsoFh+37/AV+Wl2jcNbG1CIzX1cx2KJ+2AWciBlE0046ztGuaHzpqzjeyvwxUHYTDJh= 2+t DyRCt7lrRrZuMTBlHCQw1GlSSrlPw9l1CASXto0gxnFgCpulTBHJQVPUr0XbjmT52xbmRlv3y= 4CR MCp+/0ZKzXddKZTA6XyIHuumRuKW0L1rBIfqgbUB0icE7tM/+bkYZzMExhnILF05nIIQKN5Rq= 59p t+KxrjK2t13OwU0EXMQFSAEQAL++X487itN2+5NbNK0O2iUkG6OOCK8Uiep+KpWwsfwf8rz5U= FUx Tn2EBfiTRCd9NXEMeiptjp8zsRVN2MSEv77a+aiMahUyIbI+4PUX+Y2fZRIXx7kpTn4T817iw= 19m FrSQ6c/qI88JUvmMA/r9FYbUAh0vjZEPc+WUmPnZYCShnna0pDhiJe1b3pjoxPTNA2arBkGhm= m1x th/rKN80Saf77ZtxOpRx+wiwXAKG54B6Q9fVWUzT5pRzJFPl6UEt4WaWVA8kMkbjLcv8k3fJT= MK0 ZpxjTIDFIqqYxiJIKE5TbuMvN9ilx/grUhdQ+Nu5kOJlOUiFfeqTUi/hJOljtRsh3WxJhpEmV= u+w 7/PJpLPPys1Xa7Ax6DHr/nR5iNL1tDZEjrW6/Wav7AYX8OnlZF6irml7APAusOfv4XemZfUb/= qva /pQjbJpeVYmedFyGgC96yR55bRbzXI4CHMvApRFxyUekQp09h49MvTNJ0dV3Uj9+V+PMS05OY= BIs KbRv+C9QaoCiuUK83BSd0XFvR1KuO3FRY3Dtc5zrdWuGNa0tUYAd82Dnu/pR1wmdyYdbXEcQH= uW0 Vx5Dm6TDQ1ZLNEh2ZZRqWQ8Qrppb3n5lhbjyNiPO0upJlxYl3qo6mRXzuQMoZOeH50ZPyqmZu= d+Z kHfg/Sq8PRHNdlBhtIZ6/FBTABEBAAHCw6wEGAEKACAWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5= QUC XMQFSAIbAgJACRCo1UN+znJP5cF0IAQZAQoAHRYhBDh6O3rdFXWZPESSt+BX/kgit7ZFBQJcx= AVI AAoJEOBX/kgit7ZFM28QALr4HOTaNkpLZMxJAECLxFQg8Yzg9GdUE4l6Xqeea+Qz6Hv2fO0AV= 8VQ ug7h7mFoAQQwG0lK5yHa/RF3tcApVEXMyL19AamMNnA5H0mXEUcTvge2JeVK9ONTBYjSR6llO= nUK Co24p3lnzmp6eZNEfaTPbSGo7UTmWcqfHtkvH4C5hOhDyY6GTVrgcMV2G2B1jq4evn0XxdqTi= po3 VyAMtwW/HlTHKXpXpW0QhzD+D6ioNUgyQjpPjkI3BWJHzSCWVUKgWD2EdOu+IsciDM115APvd= yeX vgWNF8jphl+PJf2inqS8iSrd4pf04//tqNhkmBHSIFh6LwPlUUMEjKI4sWUYcL8zZimUmaK9H= yZe bZq+IQFnjMw80h4iMc4YpY8mKgz4ld7wNV68+NFpgn+YaK6EVCpML91ret5kR4PyhO3tlMydY= zW3 SFmmYFIEOEn+l5V223/8RDsg7XilBPZXtYDDpCJSedo3+d9eeBTyLnaXhnmhs1N06IVMbga/x= g6B YT0OxJ7KFhyLW9SQ2+22oVqtfqGR9+Qx8UaiLnAx2a0ZjCHOspg/RTsXz7jqC8Ez9AVEPLOrw= /It IFI8Mx1AoJxfdoK9JIIsSNHeKrvCNmRK1n7NnNLa1JDRXYNgxsCD81YJzpQjtUC4KBKbFevs/= MHD Ksg/o2mlfeNy3AAEYckW7aMP/AjhDWZuUB+WoPnVO3qoaRdtt4aMRI+8Vjwsci3HHcueQa7Xs= S/J fzg85MUXqN7PozrfEBgwk5Z+kdFW+4dhiaEXntEqWUgwkExJ5ysmP597WIQG2hUpX0jwkrzdZ= q6r Z/87mHCAMgFk1Lg/6oPOQqXvBdLFlMo6RIPawC8EeROcIuszvzKR4GIEIyXyR5rflLUUFfvLr= NPk MeuxA5CKoN1IidlngMO/sH58aac2Z67k7nrNQk62QeMFQndcKb45Pt3bgPjDSB98hlAklKzuH= kxx lwreilFcBqx/8f1qeg3tTkF29RkSaP38K9RnLhrfRrt4Tz8fKTF/C6A1HqL2dMQmto14S8U2o= zq9 3xiu0oUpLFdOoqfqPxgiqbqWUFIAY4JS4J2o9HXwjFii6X7/VJ9Yj0DNCrZytvSRR24j6p2r2= HFg fEPDs6NFPGoF9vNksJhc1FViEkjt1z5vTdmu3+DRSD3QTpRUujVnUL8jr0ggoZ3CI6qjVqb8K= 2+d dubT9SxWKNbBOcNOwGtqQtw2z8FZ/2tQOvu9A44A5gCYJ5fHj9uvcvEKJe6X7hX7WBpAItZUe= Y8x D91uNSY2/uceh0pE6APHxNMRaLCKMRpyvRCHqRbA2iiLT0qF4pmwYUtYIig1TkNczbtzj38mv= H+G OQ6onUMxyW18qrqJn8LzvlhkzsFNBFzEBbgBEACo/XIhTsNMVM1XLI2qzKWWLIIIYN/uTcoum= h0A eh98saWYjg68H/fv2CZhF0CZ7JXcW3EqCjWzLnHiGXTMumYwCm5vgxic1uHTS6tv97hNPNA80= vKK Fgs/ofYM4MtzQWdLw/c7lzF6qomhbr9woKbYgwRnp8qh2C84aH6+OQv6I1t2fWE7qhoLMrSh2= EiK xeogXkyNqKzlRibBUOsjurTXg+UJt7NEnrp/qgm1m9zhAkMoadFs5bROEb24qZ7eDij1HmrM6= mUb 4OkL2PnDzkUBJ2At5otp+uUCJrATS2tAz0OGNu3ijJP94+Y1d3Nt6jC5pAI40ZcxSXMMrLFAT= XJi NYLaD/Y6tpLgXaLQF1krgtvcGVkxJ8/fJVrKVcmF8Cfnab+rbNDIxLAwWT+dor2BwDgRoRI45= cyG XB7YHstdk9kBUZqff1BrMZLGEmp+M6xE2wFPWan4kD2oIh5B14CKUMYB+CBmMlJhkIzBl2GvO= 3Hv VyywCk2EourRxjDocZxyajE/fwFuAK5emuFKrucMmsnxzZMMJdkoJmnozsBS9Oj9e8YiR+yAM= Dex x4152G6SOCR9JSxnFUBPEKOgabIPLY3eQfn0nBdh/mr/iKSg+5zj3bsbvUetvRFdTbUTFnqss= L7b 3Q5ydaL3Q6PjCO/Fe0bmLKXnY2AzY8emb3xc/wARAQABwsF2BBgBCgAgFiEEWe7QZoa1zQB2l= HAN qNVDfs5yT+UFAlzEBbgCGwwACgkQqNVDfs5yT+XL9w//VJKq2qxGxS1IGSaaowcneiRx88ZfB= Tzk takhbqXhnWFwP9vuTaHcSzRowFIVzea55k/5mQeKuTTEt7k0Yb29lwoT+iqi12V/73EBIaUK+= JT5 ZP28bnQXkkqqpRzcro4lDzi5geamt7KMsWDmYqCHyXU2xXeALnqfLv1jfsJJMeoDzLl8ql50q= m1z +u94VOXf94dlqmV9v6QWoxww2k2xNWBAeUD2YzUXAZncpXbCK1MIRFBHmbg4HAapmpFUewPfs= O4P pUEJqG1IA6rl9csZnc97BvCCha6SZMvXGrEIi/ajNfD0mU2p3Iy5F1UXNx9yJlMziQvqUziA7= MSW olT2ZYr/unSrckXUh7lAwE4tq8RhhXZ2cjL+5ubk/xGFBJycn+YKoT5gmZ+gwGrluN0VJFogf= pY2 RJbF8j8VbUR+vGKxlusgyeC7uEFAoVsIUJFQ3QaPtGmnIZgP3KSz7HsZkAwiXHJ5P6wpH3CWM= u4J aOQlOMo0NPxRZOvtfAkdDb+i4jd+YjvuJkJlur1p6yhu/02cE7/BoDONgATHZqFmYzubWtCU9= Lrf q1RnVBVnH/hLM2IxMGyBYsNDRW3FwSZh7nj6vxjijS9KsxwNiAFzNl78BKlIkHgAjWVDejezm= ncB 5ixg8G0GzKxIBt3S5nrkQNz3HBJEuIwmP7HyMbLbG27OwU0EXMQF6wEQAMUl2EK3LUUh6uunJ= 55v s0z8D0XZFpgm6cwVJgaWw+1H/bXJQR56oosOf+WUM0x1jhBVTLhI+oOK+uz1VkeZRMvTRxYob= fNq n7V5Gn8D8tO8z55yuHgHxn8T8+ZV8RzEbITDNmnK3VNC+mGvWCOe03gU6rhaE9qb3fhFreQA1= e85 XR3WqwxR/m/Vxdc0ANxgrij+VEOZDzlknAt9s93sPQDCqCGfNtRaKgVi/xvZUWvrYSBb1v5d3= wit KlADmuqWCWtc9+PuBmjUIObGP7Zll1dQ6enrtQ943ZsUujXYsdrfuaf5m47u/1G1IzwznIJwl= ZUU M2RAHQkCu+yjnXjtW0/ZEYV0RV+xZ5Qf2CtSq2rS5jpPKbtqhkzclX6ziV2ycRypR/vtbo81U= dP1 cbwSlSlxwp65Y7D+uV1F/7vI+OjUqJpD8mHgdh9OOZCWI2zHTSaH2FqS4LaT6kJIcd0sLoRPV= C3E U2vQQIM5aMyYpFlacZgmAryldp8cHwvbtpR4R2GWlXAW3w/pz2B7BD+xiUHvu2cXgeRYWgvtA= 7kw monmnhJ0NiN6cB4GPjr0ivysDNvdnnvCQ2FNMrqUGMhAK1fFh3nJF5CgMGZSyricZvE8tl7nl= XN4 TUlhhNqhSKyqHL7b0WjPhAUBNZvf1hutnl72rDAMBhTjYbEkLAl2/I5RABEBAAHCwXYEGAEKA= CAW IQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQF6wIbIAAKCRCo1UN+znJP5d4OD/9YMP8rUtR43= z0v Y1UnqMyZH9I8mOIL12AqRhsroaFb8rs3QU+u5cZGf2QvP2uOF6wFzjQGelZLjgVmctBYzutzs= jzX Id0D+B3O2KJhquRXEZ5HQlvZ6/YY0KDzNcYk2Tghg/NqvGltJtJuHrysPIL/0csA91mVUFs25= iap RwLrZfizTEzyh8KCrsV8j+c7r/UTRNkwDbTuq+s7kAyLVEWMTlBRkXg9IsxyX1F+k6xjSKRGf= XnI cct2BEYDcwNxzcPDOHpwzNCH3DCGDmuOLQGspp40liJ1cY1B7a1t3kpNRUv2YDth+jHs58BmF= Nfx WrBwv8OYulI+ehtErPTmOt6eNBhMp5EvoQuT6YwnL+2UwnA1SdNseG1y6tmgeEl/1PeGuYnze= vgk olNUS+4jzyWMG5deRldsjlHxMJBdT5VQXlXP8xb8oHQAkeR3KtlNyrtCi4R62btnIoSF7W9NY= heG aXXa2rHTVi82pqIg6p/E35MVh7X5nXIVOlGM6YXrdKapL/tRNExAW0xfrtwSJfMoxNAqFcwyR= e+i f3/7YeeVW9uqs8gSzAqD9x7JAYI2eW3JW6N3bdiZxIJ7wuk67zaW5rh36h9FhRM9KONvWbzXD= KN2 qyGMI8nCoorTHcnGOw8TqLh9cni59kQ+lEw/6d/vglsWEWhDJdt9r3ZWpMJW9w=3D=3D =3DQgWh -----END PGP PUBLIC KEY BLOCK----- --------------349AB84A6DD4E821B5C3754B-- --NQeyRYDzHIEGLBG9C99gmkWOk9k2GlzQ7--
  116404
November 16, 2021 09:16 rowan.collins@gmail.com (Rowan Tommins)
On 15/11/2021 17:20, Andreas Heigl wrote:

> 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.
I see, yes, code that is 100% perfectly tested can get away without the language performing any error checking at all - the behaviour is all guaranteed by the tests. I would be very surprised if even 1% of PHP applications can claim such comprehensive tests.
> Yes: That rips off a completely different topic: Testing "getters" and > "setters".
Unless you have zero business logic in your classes, testing getters and setters is absolutely not sufficient. Everywhere that accesses a private or protected property has the potential to mistype it and cause subtle bugs.
> 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".
Yes to both questions. A number of "uses" of this feature are not actually deliberate uses which need protecting by adding the attribute, they are mistakes that are going unnoticed in those warrens of untested, un-analysed code. Those code bases are exactly the ones that benefit from the language having the run-time checks built in. Regards, -- Rowan Tommins [IMSoP]
  116405
November 16, 2021 09:27 Andreas Heigl <andreas@heigl.org>
--Jm60aZNVX4g9ud7HU3plKrRxlxnsc4wXu
Content-Type: multipart/mixed;
 boundary="------------DCC6E4FCEE77E4F6C673C79A"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------DCC6E4FCEE77E4F6C673C79A
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hey all

On 16.11.21 10:16, Rowan Tommins wrote:
> On 15/11/2021 17:20, Andreas Heigl wrote: >=20 >> When you are testing whether writing 'X' to a property and then=20 >> reading from that property gives that 'X' back, then everything should= =20
>> be good.=20 >=20 >=20 > I see, yes, code that is 100% perfectly tested can get away without the= =20
> language performing any error checking at all - the behaviour is all=20 > guaranteed by the tests. I would be very surprised if even 1% of PHP=20 > applications can claim such comprehensive tests.
The topic here was that new code can verify the declaration of a=20 property by using tests. That does not need to happen on the language=20 level. I was never talking about adding tests for existing code.
>=20 >=20 >> Yes: That rips off a completely different topic: Testing "getters" and= =20
>> "setters".=20 >=20 >=20 > Unless you have zero business logic in your classes, testing getters an= d=20
> setters is absolutely not sufficient. Everywhere that accesses a privat= e=20
> or protected property has the potential to mistype it and cause subtle =
> bugs. >=20 >=20 >> That is absolutely correct. The main question is: "Do we *need* to=20 >> spot this behaviour in old code"? Not "Do we *want* to spot this=20 >> behaviour in old code".=20 >=20 >=20 > Yes to both questions. A number of "uses" of this feature are not=20 > actually deliberate uses which need protecting by adding the attribute,= =20
> they are mistakes that are going unnoticed in those warrens of untested= ,=20
> un-analysed code. Those code bases are exactly the ones that benefit=20 > from the language having the run-time checks built in.
That highly depends on your view-point. There are a lot of people out=20 there that do not require that this behaviour *needs* to be spotted. Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --------------DCC6E4FCEE77E4F6C673C79A Content-Type: application/pgp-keys; name="OpenPGP_0xA8D5437ECE724FE5.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xA8D5437ECE724FE5.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFzEA7MBEACpvo0AbmZG6lUGMvDUebQcYVjOPrdqtnlb2WoZH9FrJyHyenzejO29VCjue= kdh u44sUNgEHXxExUekguLDGZOzC9926g2rGDWO3MU1oqRlKURnOWsp/i0d9WM07ihj/lL6smT9Y= Lea gtPCJporUiFW8JyIusBWWhlL8hp8ZDvEfmvi06xDXML3wXzH/KWmoew3LgdwCZPkQSIWemUDP= ZKc UL8eeVkhYIJA9VKQnGSx36p5T7Ch/l+iqiPlyY1GUNItX9AQjpr07V0kIjyK+yHn6Aw1uy1xW= rLn 7ATDX8YuMvaz72+c/P2zQReMWoZNfggd2FHOPRUHvHcC9C91PuzJh8e9hvtU/szDrPvvCVpg5= aRy mN/YPFJBSEqZfDelhD+8A1TJNPqSyzc21Qdd61636ynryawIW+HxFT/UN1eA7V5/fdjeRyNUJ= d7B 99Vo5A/lI25bIpg6cPLOLpVPFHEpNlGPQ8pcMRwnjG9GR74PTfH7Dy8Ksq8lpygPljJInZbz0= 870 cHlM5XSdIPTXWQFfJi0e2kfaLCEni/Vih+eL0e5F7X3RtaXY0HRFYHX8dY7ojf3sZJjdPVm3A= QXY 1yNkjnRxyJ/4gIwdFwYplU6lRBL92jdDLavPWVK4Dsil/woKmsCpxClWfU/MzmQlhbdH+x8V2= SYO a4aJWiixx59DxQARAQABzSFBbmRyZWFzIEhlaWdsIDxhbmRyZWFzQGhlaWdsLm9yZz7CwY4EE= wEK ADgWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQDswIbAwULCQgHAwUVCgkICwUWAgMBAAIeA= QIX gAAKCRCo1UN+znJP5clsD/4vnmCp5oVIXdNXkK3PNajHR1ddpr2+Ake+bo6TS801MSd638f2U= g/e Qmu6j0XuHbgJql9wnoDh0Oq47bPxGTszPbbhD0FL1s6YBDqJKcz2okbmYRutumC52u4h8dGxb= VjC M9le1rckK54aDjkzL27iGRNfQLw1vg9gdl1yRz866bZ75MItk/7BewJrodQ5zweNcDVOmYseP= Lpo 13peB1mzDP/tuBH4CpoeDtAb/+Rc5Qv/J6P7iMDC4fPbFIl5//Ge7blMV98seXOAYMCvDYmLc= JFb nESBla/8te8lKE2E1PjwnIeMvDfYHn17CYd2UqnmlQbJbN30/Y2eiPT9w7wjrgc+qGRWEU+hu= GMl rDXQmmAtHPADf08QwOWpDVoZ+WFsQEB3f2fsZtfOnxXv8yb+Q16kVcPWaRyvusT5KLT39h2Vv= Zlh H8uporNimjs7+Rl8Fs7PP6n2L+OCnI1sSCTixBQT4MDNM6IVxqhy5j8M9ig3vR7czJgVVsDmK= CFi gOibvIFgxfRH2A7JjyplO034eUw7I3IJdffuBWjZ8SCfwZ3sS67UaPy01UVovSQKikEJBfADE= cl4 X25YsHvHXCksYLoZHb6wvtFzUrjxXwipwzlWtNBR2gTB2lCfeCLcwYcHdN8qcgg+emxDkBHeL= /Ml w5OLGW86dy6ha3BJDQgdL8LBcwQQAQoAHRYhBJZ8z6UN/+4Du4v18sqSE8db/ORyBQJcxBvDA= AoJ EMqSE8db/ORyHLUP/iADAMreqincMvKf8A0BMhAl79ZFhXkcFeEvb7KreVNp9pFBqUMtpvD6M= wY8 MpX+B9ys7qL8uY01Mf4ovex+O3tDmRRDMtho7Af2bO7Dyku7gnjtR0qdb+ceMDyVbmODVoMN+= Sh8 a9bj0uY0BlCsOkDb6hYyIf1xXAHkrX4wZbbjzpwNWoTQxsJo5ho7V/7CXMBYL6nLYpXR7vmgU= ori 2FbmiDIu+sKWbDezWcTNXItkn0WpIGTGSPWMLzEIJznOFJZlBd2q+/YHKqO/3G53tl62XLBjj= 9TC u1cnScsFJKhVRjn/mcwI9rrg4tLuSIfGqAoq29YSd832r9iC8CBuHc/T7MySekxNrdxnpecHy= Ajw AI+RhF1g+fVrmeYt1+4stwfpmLp+gEFPiHxoQkKc2q8pjNRmtoKvf2Z9cqauB+8QWyIKjgrab= dJy ev/b54o+CqxNo4KSjhwSBjb/ihVw1W2AWLkEGJUysHP6r1E12dXlYrEvBm13LIP+OOqpZRY5K= MKi WNjmQF3wtEr6SjMYXcLx+1ydVQLqFa6in57YotfNqlehiU1KDhJ/AyU+tgBJ3OxShS6p4Gmia= Dvh 8qDp0bm7GxkQEA+8kOmn+4mY5E5LzzlbIkHoDqqZs/RkWoxNpXyhIx6zqqlE4yASuWwY98tco= mx8 /CClg5DoQAl2NvWPwsFzBBABCgAdFiEEclTRxmnDsSbzEk7xbQJ8ZCRit3gFAlzEHMsACgkQb= QJ8 ZCRit3jsmA/+JJUt4Bg9cJ3itTdP+0PfSVYh0xwR+ev5b0sAj2moWowk1U0IEzHhM5eHlAJ/5= s4/ peG2Bkv2vCB+mTMFCbcuZfdsF1N13MSFqJH9ZLjZY5QGo9IqAF+JI1Tu0zArKOXWI+Fs4WXaY= lp2 f+aMccVrd6LIObbgKKQzH2n4u3nxwfVsWSZcNVCvIQVI9FPexH9C4EbPN/ocxx4/Qewx/ie+s= slL M8CVULcZmJeN+rcjWR4hr2l9zY925WpbQ/LE6cmnqDWVS+SgFQGF6j1nsUJzRA2pYk/Q12o+2= ka9 1/o9pPu3Z8gEFu7ljflT3iO4G139crRNXRE00qfBQft9VvMl02iGQlCbK1ZER8Rou5yDPjfBk= MHP DoSUa45ILQqsUB/3rKT08ApA80QkgCh+cTyhvVCrZJPKWjusRn8mX9FM+lotL9ZWID9/Q90FJ= hli XyPj8gmsoFh+37/AV+Wl2jcNbG1CIzX1cx2KJ+2AWciBlE0046ztGuaHzpqzjeyvwxUHYTDJh= 2+t DyRCt7lrRrZuMTBlHCQw1GlSSrlPw9l1CASXto0gxnFgCpulTBHJQVPUr0XbjmT52xbmRlv3y= 4CR MCp+/0ZKzXddKZTA6XyIHuumRuKW0L1rBIfqgbUB0icE7tM/+bkYZzMExhnILF05nIIQKN5Rq= 59p t+KxrjK2t13OwU0EXMQFSAEQAL++X487itN2+5NbNK0O2iUkG6OOCK8Uiep+KpWwsfwf8rz5U= FUx Tn2EBfiTRCd9NXEMeiptjp8zsRVN2MSEv77a+aiMahUyIbI+4PUX+Y2fZRIXx7kpTn4T817iw= 19m FrSQ6c/qI88JUvmMA/r9FYbUAh0vjZEPc+WUmPnZYCShnna0pDhiJe1b3pjoxPTNA2arBkGhm= m1x th/rKN80Saf77ZtxOpRx+wiwXAKG54B6Q9fVWUzT5pRzJFPl6UEt4WaWVA8kMkbjLcv8k3fJT= MK0 ZpxjTIDFIqqYxiJIKE5TbuMvN9ilx/grUhdQ+Nu5kOJlOUiFfeqTUi/hJOljtRsh3WxJhpEmV= u+w 7/PJpLPPys1Xa7Ax6DHr/nR5iNL1tDZEjrW6/Wav7AYX8OnlZF6irml7APAusOfv4XemZfUb/= qva /pQjbJpeVYmedFyGgC96yR55bRbzXI4CHMvApRFxyUekQp09h49MvTNJ0dV3Uj9+V+PMS05OY= BIs KbRv+C9QaoCiuUK83BSd0XFvR1KuO3FRY3Dtc5zrdWuGNa0tUYAd82Dnu/pR1wmdyYdbXEcQH= uW0 Vx5Dm6TDQ1ZLNEh2ZZRqWQ8Qrppb3n5lhbjyNiPO0upJlxYl3qo6mRXzuQMoZOeH50ZPyqmZu= d+Z kHfg/Sq8PRHNdlBhtIZ6/FBTABEBAAHCw6wEGAEKACAWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5= QUC XMQFSAIbAgJACRCo1UN+znJP5cF0IAQZAQoAHRYhBDh6O3rdFXWZPESSt+BX/kgit7ZFBQJcx= AVI AAoJEOBX/kgit7ZFM28QALr4HOTaNkpLZMxJAECLxFQg8Yzg9GdUE4l6Xqeea+Qz6Hv2fO0AV= 8VQ ug7h7mFoAQQwG0lK5yHa/RF3tcApVEXMyL19AamMNnA5H0mXEUcTvge2JeVK9ONTBYjSR6llO= nUK Co24p3lnzmp6eZNEfaTPbSGo7UTmWcqfHtkvH4C5hOhDyY6GTVrgcMV2G2B1jq4evn0XxdqTi= po3 VyAMtwW/HlTHKXpXpW0QhzD+D6ioNUgyQjpPjkI3BWJHzSCWVUKgWD2EdOu+IsciDM115APvd= yeX vgWNF8jphl+PJf2inqS8iSrd4pf04//tqNhkmBHSIFh6LwPlUUMEjKI4sWUYcL8zZimUmaK9H= yZe bZq+IQFnjMw80h4iMc4YpY8mKgz4ld7wNV68+NFpgn+YaK6EVCpML91ret5kR4PyhO3tlMydY= zW3 SFmmYFIEOEn+l5V223/8RDsg7XilBPZXtYDDpCJSedo3+d9eeBTyLnaXhnmhs1N06IVMbga/x= g6B YT0OxJ7KFhyLW9SQ2+22oVqtfqGR9+Qx8UaiLnAx2a0ZjCHOspg/RTsXz7jqC8Ez9AVEPLOrw= /It IFI8Mx1AoJxfdoK9JIIsSNHeKrvCNmRK1n7NnNLa1JDRXYNgxsCD81YJzpQjtUC4KBKbFevs/= MHD Ksg/o2mlfeNy3AAEYckW7aMP/AjhDWZuUB+WoPnVO3qoaRdtt4aMRI+8Vjwsci3HHcueQa7Xs= S/J fzg85MUXqN7PozrfEBgwk5Z+kdFW+4dhiaEXntEqWUgwkExJ5ysmP597WIQG2hUpX0jwkrzdZ= q6r Z/87mHCAMgFk1Lg/6oPOQqXvBdLFlMo6RIPawC8EeROcIuszvzKR4GIEIyXyR5rflLUUFfvLr= NPk MeuxA5CKoN1IidlngMO/sH58aac2Z67k7nrNQk62QeMFQndcKb45Pt3bgPjDSB98hlAklKzuH= kxx lwreilFcBqx/8f1qeg3tTkF29RkSaP38K9RnLhrfRrt4Tz8fKTF/C6A1HqL2dMQmto14S8U2o= zq9 3xiu0oUpLFdOoqfqPxgiqbqWUFIAY4JS4J2o9HXwjFii6X7/VJ9Yj0DNCrZytvSRR24j6p2r2= HFg fEPDs6NFPGoF9vNksJhc1FViEkjt1z5vTdmu3+DRSD3QTpRUujVnUL8jr0ggoZ3CI6qjVqb8K= 2+d dubT9SxWKNbBOcNOwGtqQtw2z8FZ/2tQOvu9A44A5gCYJ5fHj9uvcvEKJe6X7hX7WBpAItZUe= Y8x D91uNSY2/uceh0pE6APHxNMRaLCKMRpyvRCHqRbA2iiLT0qF4pmwYUtYIig1TkNczbtzj38mv= H+G OQ6onUMxyW18qrqJn8LzvlhkzsFNBFzEBbgBEACo/XIhTsNMVM1XLI2qzKWWLIIIYN/uTcoum= h0A eh98saWYjg68H/fv2CZhF0CZ7JXcW3EqCjWzLnHiGXTMumYwCm5vgxic1uHTS6tv97hNPNA80= vKK Fgs/ofYM4MtzQWdLw/c7lzF6qomhbr9woKbYgwRnp8qh2C84aH6+OQv6I1t2fWE7qhoLMrSh2= EiK xeogXkyNqKzlRibBUOsjurTXg+UJt7NEnrp/qgm1m9zhAkMoadFs5bROEb24qZ7eDij1HmrM6= mUb 4OkL2PnDzkUBJ2At5otp+uUCJrATS2tAz0OGNu3ijJP94+Y1d3Nt6jC5pAI40ZcxSXMMrLFAT= XJi NYLaD/Y6tpLgXaLQF1krgtvcGVkxJ8/fJVrKVcmF8Cfnab+rbNDIxLAwWT+dor2BwDgRoRI45= cyG XB7YHstdk9kBUZqff1BrMZLGEmp+M6xE2wFPWan4kD2oIh5B14CKUMYB+CBmMlJhkIzBl2GvO= 3Hv VyywCk2EourRxjDocZxyajE/fwFuAK5emuFKrucMmsnxzZMMJdkoJmnozsBS9Oj9e8YiR+yAM= Dex x4152G6SOCR9JSxnFUBPEKOgabIPLY3eQfn0nBdh/mr/iKSg+5zj3bsbvUetvRFdTbUTFnqss= L7b 3Q5ydaL3Q6PjCO/Fe0bmLKXnY2AzY8emb3xc/wARAQABwsF2BBgBCgAgFiEEWe7QZoa1zQB2l= HAN qNVDfs5yT+UFAlzEBbgCGwwACgkQqNVDfs5yT+XL9w//VJKq2qxGxS1IGSaaowcneiRx88ZfB= Tzk takhbqXhnWFwP9vuTaHcSzRowFIVzea55k/5mQeKuTTEt7k0Yb29lwoT+iqi12V/73EBIaUK+= JT5 ZP28bnQXkkqqpRzcro4lDzi5geamt7KMsWDmYqCHyXU2xXeALnqfLv1jfsJJMeoDzLl8ql50q= m1z +u94VOXf94dlqmV9v6QWoxww2k2xNWBAeUD2YzUXAZncpXbCK1MIRFBHmbg4HAapmpFUewPfs= O4P pUEJqG1IA6rl9csZnc97BvCCha6SZMvXGrEIi/ajNfD0mU2p3Iy5F1UXNx9yJlMziQvqUziA7= MSW olT2ZYr/unSrckXUh7lAwE4tq8RhhXZ2cjL+5ubk/xGFBJycn+YKoT5gmZ+gwGrluN0VJFogf= pY2 RJbF8j8VbUR+vGKxlusgyeC7uEFAoVsIUJFQ3QaPtGmnIZgP3KSz7HsZkAwiXHJ5P6wpH3CWM= u4J aOQlOMo0NPxRZOvtfAkdDb+i4jd+YjvuJkJlur1p6yhu/02cE7/BoDONgATHZqFmYzubWtCU9= Lrf q1RnVBVnH/hLM2IxMGyBYsNDRW3FwSZh7nj6vxjijS9KsxwNiAFzNl78BKlIkHgAjWVDejezm= ncB 5ixg8G0GzKxIBt3S5nrkQNz3HBJEuIwmP7HyMbLbG27OwU0EXMQF6wEQAMUl2EK3LUUh6uunJ= 55v s0z8D0XZFpgm6cwVJgaWw+1H/bXJQR56oosOf+WUM0x1jhBVTLhI+oOK+uz1VkeZRMvTRxYob= fNq n7V5Gn8D8tO8z55yuHgHxn8T8+ZV8RzEbITDNmnK3VNC+mGvWCOe03gU6rhaE9qb3fhFreQA1= e85 XR3WqwxR/m/Vxdc0ANxgrij+VEOZDzlknAt9s93sPQDCqCGfNtRaKgVi/xvZUWvrYSBb1v5d3= wit KlADmuqWCWtc9+PuBmjUIObGP7Zll1dQ6enrtQ943ZsUujXYsdrfuaf5m47u/1G1IzwznIJwl= ZUU M2RAHQkCu+yjnXjtW0/ZEYV0RV+xZ5Qf2CtSq2rS5jpPKbtqhkzclX6ziV2ycRypR/vtbo81U= dP1 cbwSlSlxwp65Y7D+uV1F/7vI+OjUqJpD8mHgdh9OOZCWI2zHTSaH2FqS4LaT6kJIcd0sLoRPV= C3E U2vQQIM5aMyYpFlacZgmAryldp8cHwvbtpR4R2GWlXAW3w/pz2B7BD+xiUHvu2cXgeRYWgvtA= 7kw monmnhJ0NiN6cB4GPjr0ivysDNvdnnvCQ2FNMrqUGMhAK1fFh3nJF5CgMGZSyricZvE8tl7nl= XN4 TUlhhNqhSKyqHL7b0WjPhAUBNZvf1hutnl72rDAMBhTjYbEkLAl2/I5RABEBAAHCwXYEGAEKA= CAW IQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQF6wIbIAAKCRCo1UN+znJP5d4OD/9YMP8rUtR43= z0v Y1UnqMyZH9I8mOIL12AqRhsroaFb8rs3QU+u5cZGf2QvP2uOF6wFzjQGelZLjgVmctBYzutzs= jzX Id0D+B3O2KJhquRXEZ5HQlvZ6/YY0KDzNcYk2Tghg/NqvGltJtJuHrysPIL/0csA91mVUFs25= iap RwLrZfizTEzyh8KCrsV8j+c7r/UTRNkwDbTuq+s7kAyLVEWMTlBRkXg9IsxyX1F+k6xjSKRGf= XnI cct2BEYDcwNxzcPDOHpwzNCH3DCGDmuOLQGspp40liJ1cY1B7a1t3kpNRUv2YDth+jHs58BmF= Nfx WrBwv8OYulI+ehtErPTmOt6eNBhMp5EvoQuT6YwnL+2UwnA1SdNseG1y6tmgeEl/1PeGuYnze= vgk olNUS+4jzyWMG5deRldsjlHxMJBdT5VQXlXP8xb8oHQAkeR3KtlNyrtCi4R62btnIoSF7W9NY= heG aXXa2rHTVi82pqIg6p/E35MVh7X5nXIVOlGM6YXrdKapL/tRNExAW0xfrtwSJfMoxNAqFcwyR= e+i f3/7YeeVW9uqs8gSzAqD9x7JAYI2eW3JW6N3bdiZxIJ7wuk67zaW5rh36h9FhRM9KONvWbzXD= KN2 qyGMI8nCoorTHcnGOw8TqLh9cni59kQ+lEw/6d/vglsWEWhDJdt9r3ZWpMJW9w=3D=3D =3DQgWh -----END PGP PUBLIC KEY BLOCK----- --------------DCC6E4FCEE77E4F6C673C79A-- --Jm60aZNVX4g9ud7HU3plKrRxlxnsc4wXu--
  116407
November 16, 2021 10:23 rowan.collins@gmail.com (Rowan Tommins)
On 16/11/2021 09:27, Andreas Heigl wrote:
> >> I see, yes, code that is 100% perfectly tested can get away without >> the language performing any error checking at all - the behaviour is >> all guaranteed by the tests. I would be very surprised if even 1% of >> PHP applications can claim such comprehensive tests. > > The topic here was that new code can verify the declaration of a > property by using tests. That does not need to happen on the language > level. I was never talking about adding tests for existing code.
Whether the code is "new" or "old" is not what matters; what matters is whether the test suite is comprehensive enough that every possible mistake will be caught by a test. If it will, we can remove a whole bunch of language features - why use parameter and property types, for instance, if your tests guarantee that they will always be given correct values? For most code bases, even new ones being written from scratch in PHP 8.0, that level of testing simply doesn't exist, and having the language tell you "hey, you wrote $this->loger instead of $this->logger" is a useful feature. And, in a lot of cases, more useful than having the language say "OK, I've created your dynamic $loger property for you", which is what currently happens. Regards, -- Rowan Tommins [IMSoP]
  116414
November 16, 2021 14:59 neclimdul@gmail.com (James Gilliland)
On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins collins@gmail.com>
wrote:

> On 16/11/2021 09:27, Andreas Heigl wrote: > > > >> I see, yes, code that is 100% perfectly tested can get away without > >> the language performing any error checking at all - the behaviour is > >> all guaranteed by the tests. I would be very surprised if even 1% of > >> PHP applications can claim such comprehensive tests. > > > > The topic here was that new code can verify the declaration of a > > property by using tests. That does not need to happen on the language > > level. I was never talking about adding tests for existing code. > > > > For most code bases, even new ones being written from scratch in PHP > 8.0, that level of testing simply doesn't exist, and having the language > tell you "hey, you wrote $this->loger instead of $this->logger" is a > useful feature. And, in a lot of cases, more useful than having the > language say "OK, I've created your dynamic $loger property for you", > which is what currently happens. >
What you described there sounds like a warning and not a fatal error. Maybe that's where some of the trepidation is coming from. I know I'm less worried about the deprecation notice and more worried about what happens in PHP 9 when it's a fatal error.
  116415
November 16, 2021 15:26 deleugyn@gmail.com (Deleu)
On Tue, Nov 16, 2021 at 3:59 PM James Gilliland <neclimdul@gmail.com> wrote:

> On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins collins@gmail.com> > wrote: > > > On 16/11/2021 09:27, Andreas Heigl wrote: > > > > > >> I see, yes, code that is 100% perfectly tested can get away without > > >> the language performing any error checking at all - the behaviour is > > >> all guaranteed by the tests. I would be very surprised if even 1% of > > >> PHP applications can claim such comprehensive tests. > > > > > > The topic here was that new code can verify the declaration of a > > > property by using tests. That does not need to happen on the language > > > level. I was never talking about adding tests for existing code. > > > > > > > > For most code bases, even new ones being written from scratch in PHP > > 8.0, that level of testing simply doesn't exist, and having the language > > tell you "hey, you wrote $this->loger instead of $this->logger" is a > > useful feature. And, in a lot of cases, more useful than having the > > language say "OK, I've created your dynamic $loger property for you", > > which is what currently happens. > > > > What you described there sounds like a warning and not a fatal error. Maybe > that's where some of the trepidation is coming from. I know I'm less > worried about the deprecation notice and more worried about what happens in > PHP 9 when it's a fatal error. >
I can't say that this line of reasoning has its merits, but then there's no benefit to the engine itself. Issuing a warning and carry on materializing dynamic properties will never bring the original performance improvement that was part of the original state of the RFC. -- Marco Aurélio Deleu
  116416
November 16, 2021 16:00 Andreas Heigl <andreas@heigl.org>
--BDMuKZxW0a2WrqgLri8TmqhBoU06AG7hg
Content-Type: multipart/mixed;
 boundary="------------F16981764FC49360954F6486"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------F16981764FC49360954F6486
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hey list.

On 16.11.21 16:26, Deleu wrote:
> On Tue, Nov 16, 2021 at 3:59 PM James Gilliland <neclimdul@gmail.com> w= rote:
>=20 >> On Tue, Nov 16, 2021 at 4:23 AM Rowan Tommins collins@gmail.com= > >> wrote: >> >>> On 16/11/2021 09:27, Andreas Heigl wrote: >>>> >>>>> I see, yes, code that is 100% perfectly tested can get away without=
>>>>> the language performing any error checking at all - the behaviour i= s
>>>>> all guaranteed by the tests. I would be very surprised if even 1% o= f
>>>>> PHP applications can claim such comprehensive tests. >>>> >>>> The topic here was that new code can verify the declaration of a >>>> property by using tests. That does not need to happen on the languag= e
>>>> level. I was never talking about adding tests for existing code. >>> >>> >>> >>> For most code bases, even new ones being written from scratch in PHP >>> 8.0, that level of testing simply doesn't exist, and having the langu= age
>>> tell you "hey, you wrote $this->loger instead of $this->logger" is a >>> useful feature. And, in a lot of cases, more useful than having the >>> language say "OK, I've created your dynamic $loger property for you",=
>>> which is what currently happens. >>> >> >> What you described there sounds like a warning and not a fatal error. = Maybe
>> that's where some of the trepidation is coming from. I know I'm less >> worried about the deprecation notice and more worried about what happe= ns in
>> PHP 9 when it's a fatal error. >> >=20 > I can't say that this line of reasoning has its merits, but then there'= s no
> benefit to the engine itself. Issuing a warning and carry on materializ= ing
> dynamic properties will never bring the original performance improvemen= t
> that was part of the original state of the RFC.
Which performance improvement of the "original state" of the RFC? As=20 that was one of the questions that were not 100% answered: What are the=20 benefits for the language. And while those 8 bit that Nikita mentioned=20 in the "Motivation" part of the RFC look nice, he also stated that "this = is a fairly long-term benefit that will require additional technical=20 work to realize". Or did I miss something? Cheers Andreas --=20 ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50=C2=B022'59.5" E 08=C2=B0= 23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+ --------------F16981764FC49360954F6486 Content-Type: application/pgp-keys; name="OpenPGP_0xA8D5437ECE724FE5.asc" Content-Transfer-Encoding: quoted-printable Content-Description: OpenPGP public key Content-Disposition: attachment; filename="OpenPGP_0xA8D5437ECE724FE5.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFzEA7MBEACpvo0AbmZG6lUGMvDUebQcYVjOPrdqtnlb2WoZH9FrJyHyenzejO29VCjue= kdh u44sUNgEHXxExUekguLDGZOzC9926g2rGDWO3MU1oqRlKURnOWsp/i0d9WM07ihj/lL6smT9Y= Lea gtPCJporUiFW8JyIusBWWhlL8hp8ZDvEfmvi06xDXML3wXzH/KWmoew3LgdwCZPkQSIWemUDP= ZKc UL8eeVkhYIJA9VKQnGSx36p5T7Ch/l+iqiPlyY1GUNItX9AQjpr07V0kIjyK+yHn6Aw1uy1xW= rLn 7ATDX8YuMvaz72+c/P2zQReMWoZNfggd2FHOPRUHvHcC9C91PuzJh8e9hvtU/szDrPvvCVpg5= aRy mN/YPFJBSEqZfDelhD+8A1TJNPqSyzc21Qdd61636ynryawIW+HxFT/UN1eA7V5/fdjeRyNUJ= d7B 99Vo5A/lI25bIpg6cPLOLpVPFHEpNlGPQ8pcMRwnjG9GR74PTfH7Dy8Ksq8lpygPljJInZbz0= 870 cHlM5XSdIPTXWQFfJi0e2kfaLCEni/Vih+eL0e5F7X3RtaXY0HRFYHX8dY7ojf3sZJjdPVm3A= QXY 1yNkjnRxyJ/4gIwdFwYplU6lRBL92jdDLavPWVK4Dsil/woKmsCpxClWfU/MzmQlhbdH+x8V2= SYO a4aJWiixx59DxQARAQABzSFBbmRyZWFzIEhlaWdsIDxhbmRyZWFzQGhlaWdsLm9yZz7CwY4EE= wEK ADgWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQDswIbAwULCQgHAwUVCgkICwUWAgMBAAIeA= QIX gAAKCRCo1UN+znJP5clsD/4vnmCp5oVIXdNXkK3PNajHR1ddpr2+Ake+bo6TS801MSd638f2U= g/e Qmu6j0XuHbgJql9wnoDh0Oq47bPxGTszPbbhD0FL1s6YBDqJKcz2okbmYRutumC52u4h8dGxb= VjC M9le1rckK54aDjkzL27iGRNfQLw1vg9gdl1yRz866bZ75MItk/7BewJrodQ5zweNcDVOmYseP= Lpo 13peB1mzDP/tuBH4CpoeDtAb/+Rc5Qv/J6P7iMDC4fPbFIl5//Ge7blMV98seXOAYMCvDYmLc= JFb nESBla/8te8lKE2E1PjwnIeMvDfYHn17CYd2UqnmlQbJbN30/Y2eiPT9w7wjrgc+qGRWEU+hu= GMl rDXQmmAtHPADf08QwOWpDVoZ+WFsQEB3f2fsZtfOnxXv8yb+Q16kVcPWaRyvusT5KLT39h2Vv= Zlh H8uporNimjs7+Rl8Fs7PP6n2L+OCnI1sSCTixBQT4MDNM6IVxqhy5j8M9ig3vR7czJgVVsDmK= CFi gOibvIFgxfRH2A7JjyplO034eUw7I3IJdffuBWjZ8SCfwZ3sS67UaPy01UVovSQKikEJBfADE= cl4 X25YsHvHXCksYLoZHb6wvtFzUrjxXwipwzlWtNBR2gTB2lCfeCLcwYcHdN8qcgg+emxDkBHeL= /Ml w5OLGW86dy6ha3BJDQgdL8LBcwQQAQoAHRYhBJZ8z6UN/+4Du4v18sqSE8db/ORyBQJcxBvDA= AoJ EMqSE8db/ORyHLUP/iADAMreqincMvKf8A0BMhAl79ZFhXkcFeEvb7KreVNp9pFBqUMtpvD6M= wY8 MpX+B9ys7qL8uY01Mf4ovex+O3tDmRRDMtho7Af2bO7Dyku7gnjtR0qdb+ceMDyVbmODVoMN+= Sh8 a9bj0uY0BlCsOkDb6hYyIf1xXAHkrX4wZbbjzpwNWoTQxsJo5ho7V/7CXMBYL6nLYpXR7vmgU= ori 2FbmiDIu+sKWbDezWcTNXItkn0WpIGTGSPWMLzEIJznOFJZlBd2q+/YHKqO/3G53tl62XLBjj= 9TC u1cnScsFJKhVRjn/mcwI9rrg4tLuSIfGqAoq29YSd832r9iC8CBuHc/T7MySekxNrdxnpecHy= Ajw AI+RhF1g+fVrmeYt1+4stwfpmLp+gEFPiHxoQkKc2q8pjNRmtoKvf2Z9cqauB+8QWyIKjgrab= dJy ev/b54o+CqxNo4KSjhwSBjb/ihVw1W2AWLkEGJUysHP6r1E12dXlYrEvBm13LIP+OOqpZRY5K= MKi WNjmQF3wtEr6SjMYXcLx+1ydVQLqFa6in57YotfNqlehiU1KDhJ/AyU+tgBJ3OxShS6p4Gmia= Dvh 8qDp0bm7GxkQEA+8kOmn+4mY5E5LzzlbIkHoDqqZs/RkWoxNpXyhIx6zqqlE4yASuWwY98tco= mx8 /CClg5DoQAl2NvWPwsFzBBABCgAdFiEEclTRxmnDsSbzEk7xbQJ8ZCRit3gFAlzEHMsACgkQb= QJ8 ZCRit3jsmA/+JJUt4Bg9cJ3itTdP+0PfSVYh0xwR+ev5b0sAj2moWowk1U0IEzHhM5eHlAJ/5= s4/ peG2Bkv2vCB+mTMFCbcuZfdsF1N13MSFqJH9ZLjZY5QGo9IqAF+JI1Tu0zArKOXWI+Fs4WXaY= lp2 f+aMccVrd6LIObbgKKQzH2n4u3nxwfVsWSZcNVCvIQVI9FPexH9C4EbPN/ocxx4/Qewx/ie+s= slL M8CVULcZmJeN+rcjWR4hr2l9zY925WpbQ/LE6cmnqDWVS+SgFQGF6j1nsUJzRA2pYk/Q12o+2= ka9 1/o9pPu3Z8gEFu7ljflT3iO4G139crRNXRE00qfBQft9VvMl02iGQlCbK1ZER8Rou5yDPjfBk= MHP DoSUa45ILQqsUB/3rKT08ApA80QkgCh+cTyhvVCrZJPKWjusRn8mX9FM+lotL9ZWID9/Q90FJ= hli XyPj8gmsoFh+37/AV+Wl2jcNbG1CIzX1cx2KJ+2AWciBlE0046ztGuaHzpqzjeyvwxUHYTDJh= 2+t DyRCt7lrRrZuMTBlHCQw1GlSSrlPw9l1CASXto0gxnFgCpulTBHJQVPUr0XbjmT52xbmRlv3y= 4CR MCp+/0ZKzXddKZTA6XyIHuumRuKW0L1rBIfqgbUB0icE7tM/+bkYZzMExhnILF05nIIQKN5Rq= 59p t+KxrjK2t13OwU0EXMQFSAEQAL++X487itN2+5NbNK0O2iUkG6OOCK8Uiep+KpWwsfwf8rz5U= FUx Tn2EBfiTRCd9NXEMeiptjp8zsRVN2MSEv77a+aiMahUyIbI+4PUX+Y2fZRIXx7kpTn4T817iw= 19m FrSQ6c/qI88JUvmMA/r9FYbUAh0vjZEPc+WUmPnZYCShnna0pDhiJe1b3pjoxPTNA2arBkGhm= m1x th/rKN80Saf77ZtxOpRx+wiwXAKG54B6Q9fVWUzT5pRzJFPl6UEt4WaWVA8kMkbjLcv8k3fJT= MK0 ZpxjTIDFIqqYxiJIKE5TbuMvN9ilx/grUhdQ+Nu5kOJlOUiFfeqTUi/hJOljtRsh3WxJhpEmV= u+w 7/PJpLPPys1Xa7Ax6DHr/nR5iNL1tDZEjrW6/Wav7AYX8OnlZF6irml7APAusOfv4XemZfUb/= qva /pQjbJpeVYmedFyGgC96yR55bRbzXI4CHMvApRFxyUekQp09h49MvTNJ0dV3Uj9+V+PMS05OY= BIs KbRv+C9QaoCiuUK83BSd0XFvR1KuO3FRY3Dtc5zrdWuGNa0tUYAd82Dnu/pR1wmdyYdbXEcQH= uW0 Vx5Dm6TDQ1ZLNEh2ZZRqWQ8Qrppb3n5lhbjyNiPO0upJlxYl3qo6mRXzuQMoZOeH50ZPyqmZu= d+Z kHfg/Sq8PRHNdlBhtIZ6/FBTABEBAAHCw6wEGAEKACAWIQRZ7tBmhrXNAHaUcA2o1UN+znJP5= QUC XMQFSAIbAgJACRCo1UN+znJP5cF0IAQZAQoAHRYhBDh6O3rdFXWZPESSt+BX/kgit7ZFBQJcx= AVI AAoJEOBX/kgit7ZFM28QALr4HOTaNkpLZMxJAECLxFQg8Yzg9GdUE4l6Xqeea+Qz6Hv2fO0AV= 8VQ ug7h7mFoAQQwG0lK5yHa/RF3tcApVEXMyL19AamMNnA5H0mXEUcTvge2JeVK9ONTBYjSR6llO= nUK Co24p3lnzmp6eZNEfaTPbSGo7UTmWcqfHtkvH4C5hOhDyY6GTVrgcMV2G2B1jq4evn0XxdqTi= po3 VyAMtwW/HlTHKXpXpW0QhzD+D6ioNUgyQjpPjkI3BWJHzSCWVUKgWD2EdOu+IsciDM115APvd= yeX vgWNF8jphl+PJf2inqS8iSrd4pf04//tqNhkmBHSIFh6LwPlUUMEjKI4sWUYcL8zZimUmaK9H= yZe bZq+IQFnjMw80h4iMc4YpY8mKgz4ld7wNV68+NFpgn+YaK6EVCpML91ret5kR4PyhO3tlMydY= zW3 SFmmYFIEOEn+l5V223/8RDsg7XilBPZXtYDDpCJSedo3+d9eeBTyLnaXhnmhs1N06IVMbga/x= g6B YT0OxJ7KFhyLW9SQ2+22oVqtfqGR9+Qx8UaiLnAx2a0ZjCHOspg/RTsXz7jqC8Ez9AVEPLOrw= /It IFI8Mx1AoJxfdoK9JIIsSNHeKrvCNmRK1n7NnNLa1JDRXYNgxsCD81YJzpQjtUC4KBKbFevs/= MHD Ksg/o2mlfeNy3AAEYckW7aMP/AjhDWZuUB+WoPnVO3qoaRdtt4aMRI+8Vjwsci3HHcueQa7Xs= S/J fzg85MUXqN7PozrfEBgwk5Z+kdFW+4dhiaEXntEqWUgwkExJ5ysmP597WIQG2hUpX0jwkrzdZ= q6r Z/87mHCAMgFk1Lg/6oPOQqXvBdLFlMo6RIPawC8EeROcIuszvzKR4GIEIyXyR5rflLUUFfvLr= NPk MeuxA5CKoN1IidlngMO/sH58aac2Z67k7nrNQk62QeMFQndcKb45Pt3bgPjDSB98hlAklKzuH= kxx lwreilFcBqx/8f1qeg3tTkF29RkSaP38K9RnLhrfRrt4Tz8fKTF/C6A1HqL2dMQmto14S8U2o= zq9 3xiu0oUpLFdOoqfqPxgiqbqWUFIAY4JS4J2o9HXwjFii6X7/VJ9Yj0DNCrZytvSRR24j6p2r2= HFg fEPDs6NFPGoF9vNksJhc1FViEkjt1z5vTdmu3+DRSD3QTpRUujVnUL8jr0ggoZ3CI6qjVqb8K= 2+d dubT9SxWKNbBOcNOwGtqQtw2z8FZ/2tQOvu9A44A5gCYJ5fHj9uvcvEKJe6X7hX7WBpAItZUe= Y8x D91uNSY2/uceh0pE6APHxNMRaLCKMRpyvRCHqRbA2iiLT0qF4pmwYUtYIig1TkNczbtzj38mv= H+G OQ6onUMxyW18qrqJn8LzvlhkzsFNBFzEBbgBEACo/XIhTsNMVM1XLI2qzKWWLIIIYN/uTcoum= h0A eh98saWYjg68H/fv2CZhF0CZ7JXcW3EqCjWzLnHiGXTMumYwCm5vgxic1uHTS6tv97hNPNA80= vKK Fgs/ofYM4MtzQWdLw/c7lzF6qomhbr9woKbYgwRnp8qh2C84aH6+OQv6I1t2fWE7qhoLMrSh2= EiK xeogXkyNqKzlRibBUOsjurTXg+UJt7NEnrp/qgm1m9zhAkMoadFs5bROEb24qZ7eDij1HmrM6= mUb 4OkL2PnDzkUBJ2At5otp+uUCJrATS2tAz0OGNu3ijJP94+Y1d3Nt6jC5pAI40ZcxSXMMrLFAT= XJi NYLaD/Y6tpLgXaLQF1krgtvcGVkxJ8/fJVrKVcmF8Cfnab+rbNDIxLAwWT+dor2BwDgRoRI45= cyG XB7YHstdk9kBUZqff1BrMZLGEmp+M6xE2wFPWan4kD2oIh5B14CKUMYB+CBmMlJhkIzBl2GvO= 3Hv VyywCk2EourRxjDocZxyajE/fwFuAK5emuFKrucMmsnxzZMMJdkoJmnozsBS9Oj9e8YiR+yAM= Dex x4152G6SOCR9JSxnFUBPEKOgabIPLY3eQfn0nBdh/mr/iKSg+5zj3bsbvUetvRFdTbUTFnqss= L7b 3Q5ydaL3Q6PjCO/Fe0bmLKXnY2AzY8emb3xc/wARAQABwsF2BBgBCgAgFiEEWe7QZoa1zQB2l= HAN qNVDfs5yT+UFAlzEBbgCGwwACgkQqNVDfs5yT+XL9w//VJKq2qxGxS1IGSaaowcneiRx88ZfB= Tzk takhbqXhnWFwP9vuTaHcSzRowFIVzea55k/5mQeKuTTEt7k0Yb29lwoT+iqi12V/73EBIaUK+= JT5 ZP28bnQXkkqqpRzcro4lDzi5geamt7KMsWDmYqCHyXU2xXeALnqfLv1jfsJJMeoDzLl8ql50q= m1z +u94VOXf94dlqmV9v6QWoxww2k2xNWBAeUD2YzUXAZncpXbCK1MIRFBHmbg4HAapmpFUewPfs= O4P pUEJqG1IA6rl9csZnc97BvCCha6SZMvXGrEIi/ajNfD0mU2p3Iy5F1UXNx9yJlMziQvqUziA7= MSW olT2ZYr/unSrckXUh7lAwE4tq8RhhXZ2cjL+5ubk/xGFBJycn+YKoT5gmZ+gwGrluN0VJFogf= pY2 RJbF8j8VbUR+vGKxlusgyeC7uEFAoVsIUJFQ3QaPtGmnIZgP3KSz7HsZkAwiXHJ5P6wpH3CWM= u4J aOQlOMo0NPxRZOvtfAkdDb+i4jd+YjvuJkJlur1p6yhu/02cE7/BoDONgATHZqFmYzubWtCU9= Lrf q1RnVBVnH/hLM2IxMGyBYsNDRW3FwSZh7nj6vxjijS9KsxwNiAFzNl78BKlIkHgAjWVDejezm= ncB 5ixg8G0GzKxIBt3S5nrkQNz3HBJEuIwmP7HyMbLbG27OwU0EXMQF6wEQAMUl2EK3LUUh6uunJ= 55v s0z8D0XZFpgm6cwVJgaWw+1H/bXJQR56oosOf+WUM0x1jhBVTLhI+oOK+uz1VkeZRMvTRxYob= fNq n7V5Gn8D8tO8z55yuHgHxn8T8+ZV8RzEbITDNmnK3VNC+mGvWCOe03gU6rhaE9qb3fhFreQA1= e85 XR3WqwxR/m/Vxdc0ANxgrij+VEOZDzlknAt9s93sPQDCqCGfNtRaKgVi/xvZUWvrYSBb1v5d3= wit KlADmuqWCWtc9+PuBmjUIObGP7Zll1dQ6enrtQ943ZsUujXYsdrfuaf5m47u/1G1IzwznIJwl= ZUU M2RAHQkCu+yjnXjtW0/ZEYV0RV+xZ5Qf2CtSq2rS5jpPKbtqhkzclX6ziV2ycRypR/vtbo81U= dP1 cbwSlSlxwp65Y7D+uV1F/7vI+OjUqJpD8mHgdh9OOZCWI2zHTSaH2FqS4LaT6kJIcd0sLoRPV= C3E U2vQQIM5aMyYpFlacZgmAryldp8cHwvbtpR4R2GWlXAW3w/pz2B7BD+xiUHvu2cXgeRYWgvtA= 7kw monmnhJ0NiN6cB4GPjr0ivysDNvdnnvCQ2FNMrqUGMhAK1fFh3nJF5CgMGZSyricZvE8tl7nl= XN4 TUlhhNqhSKyqHL7b0WjPhAUBNZvf1hutnl72rDAMBhTjYbEkLAl2/I5RABEBAAHCwXYEGAEKA= CAW IQRZ7tBmhrXNAHaUcA2o1UN+znJP5QUCXMQF6wIbIAAKCRCo1UN+znJP5d4OD/9YMP8rUtR43= z0v Y1UnqMyZH9I8mOIL12AqRhsroaFb8rs3QU+u5cZGf2QvP2uOF6wFzjQGelZLjgVmctBYzutzs= jzX Id0D+B3O2KJhquRXEZ5HQlvZ6/YY0KDzNcYk2Tghg/NqvGltJtJuHrysPIL/0csA91mVUFs25= iap RwLrZfizTEzyh8KCrsV8j+c7r/UTRNkwDbTuq+s7kAyLVEWMTlBRkXg9IsxyX1F+k6xjSKRGf= XnI cct2BEYDcwNxzcPDOHpwzNCH3DCGDmuOLQGspp40liJ1cY1B7a1t3kpNRUv2YDth+jHs58BmF= Nfx WrBwv8OYulI+ehtErPTmOt6eNBhMp5EvoQuT6YwnL+2UwnA1SdNseG1y6tmgeEl/1PeGuYnze= vgk olNUS+4jzyWMG5deRldsjlHxMJBdT5VQXlXP8xb8oHQAkeR3KtlNyrtCi4R62btnIoSF7W9NY= heG aXXa2rHTVi82pqIg6p/E35MVh7X5nXIVOlGM6YXrdKapL/tRNExAW0xfrtwSJfMoxNAqFcwyR= e+i f3/7YeeVW9uqs8gSzAqD9x7JAYI2eW3JW6N3bdiZxIJ7wuk67zaW5rh36h9FhRM9KONvWbzXD= KN2 qyGMI8nCoorTHcnGOw8TqLh9cni59kQ+lEw/6d/vglsWEWhDJdt9r3ZWpMJW9w=3D=3D =3DQgWh -----END PGP PUBLIC KEY BLOCK----- --------------F16981764FC49360954F6486-- --BDMuKZxW0a2WrqgLri8TmqhBoU06AG7hg--
  116417
November 16, 2021 16:24 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
On Tue, Nov 16, 2021 at 6:00 PM Andreas Heigl <andreas@heigl.org> wrote:

> Hey list.
> Which performance improvement of the "original state" of the RFC? As > that was one of the questions that were not 100% answered: What are the > benefits for the language. And while those 8 bit that Nikita mentioned > in the "Motivation" part of the RFC look nice, he also stated that "this > is a fairly long-term benefit that will require additional technical > work to realize". >
I think these two messages might have some information about the performance improvements: https://externals.io/message/115800#115848 https://externals.io/message/115800#115872 Yes, maybe not everything was captured in the final RFC text. I also think all the evaluated options should have been present in the RFC as it brings more context to voters. Regards, Alex
  116373
November 15, 2021 13:53 drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)
On Mon, Nov 15, 2021 at 2:52 PM Andreas Heigl <andreas@heigl.org> 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
  116387
November 15, 2021 20:02 neclimdul@gmail.com (James Gilliland)
On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans <derick@php.net> wrote:

> Dear Internals, > > On Wed, 10 Nov 2021, Nikita Popov wrote: > > > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov ppv@gmail.com> > 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.
  116388
November 15, 2021 20:05 chasepeeler@gmail.com (Chase Peeler)
On Mon, Nov 15, 2021 at 3:02 PM James Gilliland <neclimdul@gmail.com> wrote:

> On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans <derick@php.net> wrote: > > > Dear Internals, > > > > On Wed, 10 Nov 2021, Nikita Popov wrote: > > > > > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov ppv@gmail.com> > > 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 chasepeeler@gmail.com
  116389
November 15, 2021 20:11 deleugyn@gmail.com (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 > chasepeeler@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
  116392
November 15, 2021 20:39 chasepeeler@gmail.com (Chase Peeler)
On Mon, Nov 15, 2021 at 3:11 PM Deleu <deleugyn@gmail.com> 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 >> chasepeeler@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 chasepeeler@gmail.com
  116391
November 15, 2021 20:39 internals@lists.php.net ("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 ppv@gmail.com> 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
  116360
November 15, 2021 10:26 nicolas.grekas+php@gmail.com (Nicolas Grekas)
Hi Nikita, hi everybody,

Le mer. 25 août 2021 à 12:03, Nikita Popov ppv@gmail.com> 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/0000-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
  116362
November 15, 2021 11:23 kontakt@beberlei.de (Benjamin Eberlei)
On Mon, Nov 15, 2021 at 11:26 AM Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:

> Hi Nikita, hi everybody, > > Le mer. 25 août 2021 à 12:03, Nikita Popov ppv@gmail.com> 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/0000-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 >
  116366
November 15, 2021 12:29 tekiela246@gmail.com (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.
  116386
November 15, 2021 18:27 arvids.godjuks@gmail.com (Arvids Godjuks)
On Wed, Aug 25, 2021 at 1:03 PM Nikita Popov ppv@gmail.com> 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/0000-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.godjuks@gmail.com Telegram: @psihius https://t.me/psihius
  116402
November 16, 2021 09:06 rowan.collins@gmail.com (Rowan Tommins)
On 15/11/2021 18:27, Arvids Godjuks wrote:
> 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?
Just to be clear, attributes are designed in such a way that you, and third-party packages, can add this attribute *right now*, in your PHP 7.4 code, with no ill effects. In older versions, it's a comment (as long as it's on its own line); and in 8.0 and 8.1 it will be parsed as an attribute, but simply do nothing. You can add the attribute to every single class, and slowly remove it when you're confident of each class not needing it; or you can collect the E_DEPRECATED messages and add the attribute to every class mentioned. Even in PHP 9.0, there will be no subtle behaviour differences; the code will either run, or you will get an error in exactly the same circumstances as the E_DEPRECATED messages. Regards, -- Rowan Tommins [IMSoP]