Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104633
To: internals@lists.php.net
References: <2c497732-96f8-3ef0-bc18-912220fbff4d@gmail.com>
 <CADyq6sJwMaX6vYi9p4V1XVXSa-86nCH6QxmtS0KJ2PX_Cb+4JA@mail.gmail.com>
 <b7abd39f-3fd4-443f-80cd-18f86364abb6@www.fastmail.com>
 <CADyq6s+SD9U+Z+U3Vdmi7rpyLYjMwhHdrPNvwzDcJB39kvOzJA@mail.gmail.com>
Message-ID: <4b9e7784-d0c8-2c0b-f349-0d28bd6deb2f@gmail.com>
Date: Sun, 10 Mar 2019 20:19:45 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <CADyq6s+SD9U+Z+U3Vdmi7rpyLYjMwhHdrPNvwzDcJB39kvOzJA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] RFC: Locked Classes
From: rowan.collins@gmail.com (Rowan Collins)

On 10/03/2019 19:46, Marco Pivetta wrote:
> @rowan: I've stated it multiple times in the past, but if the mechanism is
> to be removed, then it should be replaced with a language-level concept of
> laziness then.


1) I'm all for adding a language-level concept of laziness. It feels 
like it could fit with a syntax for getters and setters, which has been 
discussed a few times, but never quite made it.

2) I'm not saying that the current behaviour should be removed, I'm 
saying that dynamically unsetting properties is inherently incompatible 
with declaring a class "locked".

I've actually had more than one suggestion that __get(), __set(), and 
__unset() should not be allowed at all on locked classes; in which case, 
it wouldn't matter how unset() behaved, because the lazy-loading trick 
relies on __get() as well.

Regards,

-- 
Rowan Collins
[IMSoP]