Re: [RFC] [VOTE] Typed properties v2

On Friday, September 21, 2018 10:25:50 AM CDT Rasmus Schultz wrote: > On Fri, Sep 21, 2018 at 10:24 AM Lester Caine <lester@lsces.co.uk> wrote: > > Ignoring the debate on uninitialized/null ... not all objects ARE > > invariant > > hence nullable types. > > > and there are very good reasons for not setting values for > > everything, but it seems that these types of object are deemed to be > > 'bad coding' where in fact the simply have elements that yet to be > > 'initialized' if at all for this instance of the object. > > that's what nullable types are for. > > > The constructor > > simply creates those elements that need to exit and does nothing with > > the holders for elements that have yet to be populated ... they stay null. > > hence nullable types. > > the point of using type-hints on the properties of a class is to describe > the invariant state of that class - if the state of an instance of that > class is not what the class itself prescribed/promised at the time when you > return from the constructor, what's the point? > > the only difference between using nullable vs non-nullable property > type-hints then, is whether you can set them *back* to null after setting > them to value - but it's okay for them to return from the constructor in > a "null-like" state? > > this doesn't provide *any* additional guarantees: > > class Foo { > public int $bar; > } > > $foo = new Foo(); // invalid state allowed > > $foo->bar = 123; // valid state > > $foo->bar = null; // invalid state NOT allowed?! > > Have the effects on the null coalesce operator even been considered? > > $bar = $foo->bar ?? "what"; > > Is unintialized "null-like enough" or will this trigger an error? > > Extremely confusing. > > Type-annotations are essentially assertions about the state of a program - > if you can't count on those assertions to be fulfilled (which you > can't if they're > not checked at the time of initialization) then they're not useful. > > The bottom line for me is that property type-hints were supposed to make > my programs more predictable, make the language more reliable. > > Instead, we've introduced a whole new kind of uncertainties, new ways to > write unpredictable code, a new kind of null that makes the language even > more unreliable. > > In terms of reliability, it's actually sub-par to hand-written accessors. > > Shorter syntax, reflection support, great - but ultimately at the cost of > reliability and predictable state. > > For one, what good is reflection, if it tells me I can expect a property to > be an integer, and it turns out it doesn't have a value after all? > > If you want horrible code with no guarantees, there are plenty of ways to > do that already - you don't need property type-hints for anything more than > mere convenience in the first place. Rasmus, would the "checkpoint validity checks" I suggested in another branch of this thread ameliorate your concerns, at least to some degree? I think they're as good as we'd be able to get, given the nature of PHP, but should at least cover the most common cases. --Larry Garfield

Attachment: [application/pgp-signature] This is a digitally signed message part. signature.asc