Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115806
MIME-Version: 1.0
In-Reply-To: <df1992f6-fef0-8f62-95d3-dcbc4a5b86d1@gmail.com>
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
 <df1992f6-fef0-8f62-95d3-dcbc4a5b86d1@gmail.com>
Date: Wed, 25 Aug 2021 16:05:41 +0500
Message-ID: <CAC_PL4wHGbsxvD3EFy4RrgHpRavVTDr1TdxtNCUKtpTG4wr+Gg@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties
From: 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 <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
>
>