Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103232
Date: Sat, 22 Sep 2018 23:42:18 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <CADqTB_ihF2hA2GUSZS+TXKswCnhnm0hp5uj55zvP1Gwkn9cntA@mail.gmail.com>
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com> <CADqTB_iV7+S1BoeSACGT3ED76h-MM4Oh4xx_zxXh_GXFSWiqvQ@mail.gmail.com> <a2b16925-6ccc-4313-d1ca-8032407c379d@gmail.com> <5273905.aE8IdBJUB6@vulcan> <CADqTB_ihF2hA2GUSZS+TXKswCnhnm0hp5uj55zvP1Gwkn9cntA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <D23FE5D3-4C11-424A-9837-F5F838D4CDBC@gmail.com>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: rowan.collins@gmail.com (Rowan Collins)

On 22 September 2018 20:32:04 BST, Rasmus Schultz <rasmus@mindplay=2Edk> wr=
ote:
>if you read my last post (especially the last part) carefully, you'll
>see
>why this elephant analogy is incomplete=2E
>
>the issue is not whether or not something gets in - it's much more far
>reaching than that=2E
>
>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 ge=
t in doesn't necessarily mean knowing what is already inside - BUT, knowing=
 what can get in may still useful in itself=2E

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=2E (That is, that the current implementation is sufficient=
=2E)

b) That it is vital to always know what is inside, regardless of how it go=
t there=2E (That is, that we must prevent all mechanisms where the value is=
 uninitialised=2E)

c) That there will always be some ways for the wrong thing to end up insid=
e, but that we can add checks at key moments to see if that's happened=2E (=
That is, that we should detect uninitialised values automatically at the en=
d of the constructor, and in similar places, but that there well be other w=
ays that uninitialised values can come about=2E)

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=2E That is the same position Larry is suggesting, so I'm =
not sure why you seem keen to disagree with him=2E

Regards,

--=20
Rowan Collins
[IMSoP]