Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103228
To: internals@lists.php.net
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com>
 <CAF+90c8He-6M_WAKj7B_+fcgJhos+DPQ07afjmGyoNgx7RzE7g@mail.gmail.com>
 <CALKiJKoJXxi+khw-BhPf7DCOV+J279UGBupUHBxEKcaj8re85g@mail.gmail.com>
 <4983605.CXexPrWP49@vulcan>
 <CADqTB_iV7+S1BoeSACGT3ED76h-MM4Oh4xx_zxXh_GXFSWiqvQ@mail.gmail.com>
Message-ID: <a2b16925-6ccc-4313-d1ca-8032407c379d@gmail.com>
Date: Sat, 22 Sep 2018 18:12:48 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CADqTB_iV7+S1BoeSACGT3ED76h-MM4Oh4xx_zxXh_GXFSWiqvQ@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] [VOTE] Typed properties v2
From: rowan.collins@gmail.com (Rowan Collins)

On 22/09/2018 11:15, Rasmus Schultz wrote:
>> That is, it doesn't assert that a value IS a given type, but that it can only
>> be SET TO a given type.
> That is literally the same thing - if it can only be set to a given
> type, it can only BE a given type.


Consider this analogy: if I build a house with a standard, human-sized 
door, I cannot walk an elephant through that door; however, if the 
elephant was already there, I could build the house around it. So, the 
assertion that "no elephant can get in through that door" is not the 
same as the assertion "there is no elephant inside that house". If 
you're interested in protecting your house from roaming elephants, the 
small door is probably sufficient for your needs; if you want to know 
that when you walk into a house, there is no elephant inside, you need 
other assurances.

What Larry is pointing out is that Levi and Marco are happy to make the 
door elephant-proof (prevent nulls being assigned to the properties); 
whereas you and I are looking for a stronger guarantee that there will 
never be an elephant inside (that the object will not be in an invalid 
state).


> I don't think that, and I don't expect that - I'm not suggesting we enforce
> anything statically, I'm merely suggesting that a constructor needs to satisfy
> the constraints specified by the class.

If you read carefully, that's exactly what Larry's proposal below requires.


>> To wit, could we add an engine check to scan an object and make sure its
>> objects are all type valid right-now (viz, nothing is unitialized), and then
>> call it on selected actions automatically and allow users to call it at
>> arbitrary times if they are doing more esoteric things?
> In my opinion, this is a solution to the problem we created when we decided
> every property should internally be annotated with an "initialized" boolean
> property - you have all this extra state that wasn't part of the specification
> of the class itself, and now you have to deal with that state.
>
> In my opinion, tracking this extra state *during the constructor call* is
> acceptable and necessary in a scripting language like PHP - I never
> asked for static type-checking, I'm merely asking for this check to be
> built-into the language and performed at run-time when you exit the
> constructor, e.g. at the last moment where you can feasibly perform
> this check.

I'm not sure if you've misunderstood Larry's proposal, or are just 
agreeing with it: the sentence you quote says "add an engine check" and 
"call it on selected actions automatically"; and you ask for it to be 
"built-into the language and performed at run-time"; you mention it 
happening "when you exit the constructor", and just below the part you 
quote, so does he:

> * on __construct() exit.
> * on __wakeup() exit.
> * Possibly other similar checkpoints.

The key compromise, however, is that this still doesn't guarantee that 
there is no elephant in the house: there will be ways to create an 
object that don't go through the constructor, so won't trigger this 
check; and ways to manipulate an object that will put it into an invalid 
state. Not to mention that inside the constructor, $this will be usable 
as a normal object, unlike in a true 2-phase initialisation system like 
Swift's.

In short, we will still need runtime errors for attempting to read an 
uninitialized property, but they will be much less likely to happen 
accidentally and show up a long way from their cause.


I would be interested to hear if there are any use cases that this would 
break - a static factory method can defer as much initialisation as 
needed to the constructor, and cases where the constructor is bypassed 
will also bypass the check.

Regards,

-- 
Rowan Collins
[IMSoP]