Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115804
MIME-Version: 1.0
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
 <df1992f6-fef0-8f62-95d3-dcbc4a5b86d1@gmail.com>
In-Reply-To: <df1992f6-fef0-8f62-95d3-dcbc4a5b86d1@gmail.com>
Date: Wed, 25 Aug 2021 07:52:22 -0300
Message-ID: <CAAwFBqq_SQe_kkyn1hgZ4uTteu5UOKGaosR3c_zD=b7Rpvnstg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003751b805ca600ca1"
Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties
From: flaviohbatista@gmail.com (=?UTF-8?Q?Fl=C3=A1vio_Heleno?=)

--0000000000003751b805ca600ca1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 25, 2021 at 7:46 AM Rowan Tommins <rowan.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.

--=20
Atenciosamente,

    Fl=C3=A1vio Heleno

--0000000000003751b805ca600ca1--