Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103233
MIME-Version: 1.0
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> <D23FE5D3-4C11-424A-9837-F5F838D4CDBC@gmail.com>
In-Reply-To: <D23FE5D3-4C11-424A-9837-F5F838D4CDBC@gmail.com>
Date: Sun, 23 Sep 2018 08:18:02 +0200
Message-ID: <CADqTB_h1oWExsgmxR6RHbX1Eew2YiQTGjR2PgJc=4uW4qAJHYw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007376d4057683d6f2"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Typed properties v2
From: rasmus@mindplay.dk (Rasmus Schultz)

--0000000000007376d4057683d6f2
Content-Type: text/plain; charset="UTF-8"

> 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.

I understood that, and I disagree - just knowing what can get in is not
useful or interesting in itself. It's not even a new language feature - you
can already achieve the same with a simple setter. It's just new syntax.

The only reason it's interesting to control what can get inside with type
hints, is to enable the language to do something new - something it
couldn't already do, which is to guarantee that the type enforces it's own
state specification.

I understood the analogy, and I don't agree.


On Sun, Sep 23, 2018, 00:42 Rowan Collins <rowan.collins@gmail.com> wrote:

> On 22 September 2018 20:32:04 BST, Rasmus Schultz <rasmus@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
>
>

--0000000000007376d4057683d6f2--