On Friday, September 21, 2018 10:25:50 AM CDT Rasmus Schultz wrote:
> On Fri, Sep 21, 2018 at 10:24 AM Lester Caine <les...@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
signature.asc
Description: This is a digitally signed message part.
