Hi,
Thanks for all the answers so far.
On 2/8/23 17:04, naitsi...@e.mail.de wrote:
> > Would it make sense to make "null" the default value for nullable
properties at least?
> > So that one could write
> >
> > class Test {
> > public ?string $name;
> > }
> >
> > var_dump((new Test())->name); // null
>
Yes, this would help a lot and is exactly what I am asking for.
Then the difference between typed and none-typed properties would also
disappear. Making it more favorable to use the typed ones.
Op wo 8 feb. 2023 om 17:34 schreef Tim Düsterhus <t...@bastelstu.be>:
>
>
No, I find the difference between "null" and "uninitialized" useful,
> because it makes the behavior explicit.
>
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.
Else would it be possible to make a php.ini setting for this:
only_explicit_property_init = true|false?
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.
Op wo 8 feb. 2023 om 19:12 schreef Rowan Tommins <rowan.coll...@gmail.com>:
>
> I've actually been considering a proposal to remove this difference *the
> other way around*: if a property is declared but never assigned a value,
> consistently giving an error on access, regardless of whether a type was
> declared or not.
>
>>
> Currently, properties can be in a number of different states: declared and
> assigned, undeclared, undeclared but created dynamically by assignment,
> declared without type and not yet assigned, declared with type and not yet
> assigned (Uninitialized), declared without type but then unset (distinct
> from both the unassigned and Uninitialized states) ... possibly other
> combinations I've forgotten.
>
Lol, sounds horrible indeed!
>
> Now that we have the Uninitialized state, and have deprecated dynamic
> properties, this could mostly be reduced to two: has a current valid value,
> or Uninitialized. But the details of what would need to change and when are
> the subject for a future discussion.
>
Sounds much better!
And I think that implicit null on nullable properties could fit nicely
here. For null is a valid value for a nullable.
So I still would like to ask if you can reconsider this.
nb. Maybe I should introduce myself a little bit (more): I have been a
php-programmer for about 20 years now, seen php4, 5, 7 and now 8. I did my
study on Ambi Cobol to be an application programmer, where I learned very
strict coding. From my ex (java architect) I learned oop. I have used these
programming rules/techniques in php even when it was not required.
So it is not that I want php to be less strict!!! (just to be sure 😝)
Greetz, Lydia
