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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
