Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114619
To: internals@lists.php.net
References: <CAOwTYAtc_xD6n=efmamkAy4ro4KqPKxq18-zXsNriY0280FY2g@mail.gmail.com>
Message-ID: <80fb5a8e-d770-49fd-45d5-ea6f4b004513@gmail.com>
Date: Wed, 26 May 2021 14:24:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <CAOwTYAtc_xD6n=efmamkAy4ro4KqPKxq18-zXsNriY0280FY2g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Consensus Gathering: is_initialized
From: rowan.collins@gmail.com (Rowan Tommins)

On 26/05/2021 11:13, Joe Watkins wrote:
> Hi internals,
>
> In response to: https://bugs.php.net/bug.php?id=78480
>
> I implemented: https://github.com/php/php-src/pull/7029


My general feeling remains that the "uninitialized" state is an awkward 
hack that we should be working to eliminate with better constructor 
semantics. A variable that remains uninitialised after the constructor 
almost always indicates a bug in the constructor, not a state that the 
rest of the application should care about.

On the other hand, we have already allowed unset() to produce this 
special state, with defined behaviour for __get, so possibly the genie's 
out of the bottle, and we have to embrace it as a new "type".

On the gripping hand, this is likely to lead to even more confusion 
about what exactly the different states are: properties declared with a 
type, properties declared without a type, properties not declared at 
all; all of which can be null, a non-null value, or completely unset. 
People already complain that isset() returns false for null variables (I 
disagree, but...); this function could end up even harder to explain.

Regards,

-- 
Rowan Tommins
[IMSoP]