Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116377
Message-ID: <ae25a625-20ca-bc9a-d1ee-0f7ac4eba7c7@gmail.com>
Date: Mon, 15 Nov 2021 16:52:18 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Content-Language: en-GB
To: internals@lists.php.net
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
 <CAF+90c9XwAwbA60NQgnu5btiuE_Y9n8eASnVi8TH65jK3A2C8w@mail.gmail.com>
 <alpine.DEB.2.23.453.2111150948120.4221@singlemalt.home.derickrethans.nl>
 <371ca983-2b07-ae39-3629-49cf7ff8ee64@heigl.org>
 <CAF+90c-om9Qq7YAaf_GdRxKn5e-=8WRVDvy1gC=pA2C8dH=Wqg@mail.gmail.com>
 <497ab532-a39d-389c-8bca-86768650c2f4@heigl.org>
In-Reply-To: <497ab532-a39d-389c-8bca-86768650c2f4@heigl.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties
From: 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]