> 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.coll...@gmail.com> wrote: > 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 > >
