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
On Wed, Aug 25, 2021 at 1:03 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
>
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
On Mon, Nov 15, 2021 at 11:26 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:
> Hi Nikita, hi everybody,
>
> Le mer. 25 août 2021 à 12:03, Nikita Popov a écrit
> :
>
> > Hi internals,
> >
> > I'd like to propose the deprecation of "dynamic properties", that is
> > properties that have
Hi Nikita, hi everybody,
Le mer. 25 août 2021 à 12:03, Nikita Popov a écrit :
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
>
On Mon, Aug 30, 2021 at 2:14 PM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> Le Wed, 25 Aug 2021 12:02:49 +0200,
> Nikita Popov a écrit :
> > Hi internals,
> >
> > I'd like to propose the deprecation of "dynamic properties", that is
> > properties that have not been declared in
Le Wed, 25 Aug 2021 12:02:49 +0200,
Nikita Popov a écrit :
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
>
> On Aug 26, 2021, at 11:02 PM, Pierre Joye 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.
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..
Hi Stan,
On Fri, Aug 27, 2021 at 5:10 AM Stanislav Malyshev 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
On Thu, 26 Aug 2021 at 21:20, Sara Golemon 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:
On Thu, Aug 26, 2021 at 3:34 AM Nikita Popov 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
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
> On Aug 26, 2021, at 4:04 AM, Reindl Harald (privat) wrote:
> Am 26.08.21 um 09:24 schrieb Mike Schinkel:
>> https://3v4l.org/HAkhjW#v8.0.9
>> Total execution time for 5000 iterations for BadActor = 0.351906 milliseconds
>> Total execution time for 5000 iterations for GoodActor = 0.758886
>>
On Wed, Aug 25, 2021 at 5:28 PM Sara Golemon wrote:
> On Wed, Aug 25, 2021 at 5:03 AM 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):
> >
> >
> On Aug 26, 2021, at 2:27 AM, Reindl Harald (privat) wrote:
> Am 26.08.21 um 00:59 schrieb Mike Schinkel:
>>> On Aug 25, 2021, at 6:41 PM, Reindl Harald (privat)
>>> wrote:
>>> Am 26.08.21 um 00:37 schrieb Mike Schinkel:
That said, I'd be really interested in seeing use-cases where having
> On Aug 25, 2021, at 6:41 PM, Reindl Harald (privat) wrote:
> Am 26.08.21 um 00:37 schrieb Mike Schinkel:
>> 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
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.
> On Aug 25, 2021, at 10:04 AM, Chase Peeler wrote:
>
> On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins
> 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
On Wed, Aug 25, 2021 at 3:03 AM 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):
>
>
On Wed, Aug 25, 2021 at 2:02 PM Ben Ramsey wrote:
> 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
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
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 things
> around it. It's not something that can be easily refactored since it was
> part of the design.
Since the
On Wed, Aug 25, 2021, at 10:28 AM, Sara Golemon wrote:
> On Wed, Aug 25, 2021 at 5:03 AM 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):
> >
> >
On Wed, Aug 25, 2021 at 5:03 AM 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
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
On Wed, Aug 25, 2021 at 4:26 PM tyson andre
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):
> >
> >
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
> 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
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
On Wed, Aug 25, 2021 at 9:51 AM Rowan Tommins
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,
On Wed, Aug 25, 2021 at 3:51 PM Rowan Tommins
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,
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
On Wed, Aug 25, 2021 at 12:45 PM Rowan Tommins
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):
> >
> >
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
>
> 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
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;
/* *
Hey Nikita
On Wed, Aug 25, 2021 at 12:03 PM Nikita Popov wrote:
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
>
On Wed, Aug 25, 2021 at 7:46 AM Rowan Tommins
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):
> >
> >
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
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
On Wed, Aug 25, 2021 at 12:03 PM Nikita Popov wrote:
> This RFC takes the more direct route of deprecating this functionality
> entirely. I expect that this will have relatively little impact on modern
> code (e.g. in Symfony I could fix the vast majority of deprecation warnings
> with a
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.
43 matches
Mail list logo
