Hi
On 2/12/23 12:11, Lydia de Jongh wrote:
In case I make a mistake and accidentally don't assign a value to the
property when I should've, perhaps I've forgot to call the necessary
setter in my constructor. If I later access the property it will blow up
instead of silently feeding me garbage data.
I think this should not be an argument on this level.
The features of a programming-language should not be about preventing
mistakes, imho.
Why not? The primary (and possibly only) reason for an expressive type
system is preventing mistakes from happening and thus cutting down the
time spent writing tests and debugging. Preventing as many (expensive)
mistakes from happening as possible is also one of the selling points of
modern programming languages like Rust.
Else would it be possible to make a php.ini setting for this:
only_explicit_property_init = true|false?
New php.ini settings that change the behavior of code depending on where
it's run are generally ill-received nowadays. Library authors would need
to take care to support all possible options for the setting, which in
this case would effectively mean making all initialization explicit,
nullifying whatever benefit the option would bring in the first place.
Adding special logic for nullable properties to save the developer from
typing the 7 characters '= null;' in some rare cases, does not sound
useful to me.
For me it is about the cluttering in an otherwise clean property list.
On the other hand, so many new features in php8 are about less coding.
Shorter ifs, nullable operators, setting properties directly in
constructor.....
For a long time I refused to use those, and used the longer typing, because
it is seen better, more explicit 😇 and so gives less errors.
$oObject?->test()
is much easier overlooked then:
if($oObject){
$oObject->test();
}
So I do not understand why things like this may not be about less coding.
I'm not sure the comparison holds. Staying with your example for the
null-safe operator:
Using the null-safe operator is still explicit about the developer's
intent: The question-mark makes it clear that the developer thought
about the fact that the object variable might be null and that
short-circuiting to null is the right thing to do.
Allowing leaving out a default value for the property can mean both "I
explicitly want it to be null" and "I forgot to set the property".
Whereas with the current situation of "uninitialized", the former is
explicit and the latter will result in an easily detectable error,
instead of silently continuing execution with garbage data.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
