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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
