Re: [RFC] [VOTE] Typed properties v2

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]