On 22 September 2018 20:32:04 BST, Rasmus Schultz <ras...@mindplay.dk> wrote: >if you read my last post (especially the last part) carefully, you'll >see >why this elephant analogy is incomplete. > >the issue is not whether or not something gets in - it's much more far >reaching than that. > >the issue is, once something gets in, can you even be sure that that >something is what it claims to be?
That is the entire point of the elephant analogy: that knowing what can get in doesn't necessarily mean knowing what is already inside - BUT, knowing what can get in may still useful in itself. The positions being expressed are therefore, roughly: a) That it's not the job of this feature to prove what is inside, only to guard the door. (That is, that the current implementation is sufficient.) b) That it is vital to always know what is inside, regardless of how it got there. (That is, that we must prevent all mechanisms where the value is uninitialised.) c) That there will always be some ways for the wrong thing to end up inside, but that we can add checks at key moments to see if that's happened. (That is, that we should detect uninitialised values automatically at the end of the constructor, and in similar places, but that there well be other ways that uninitialised values can come about.) In your last message, you seemed to be accepting position c - that not all scenarios could be prevented, but that the common case of the constructor should be checked. That is the same position Larry is suggesting, so I'm not sure why you seem keen to disagree with him. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
