'Uninitialized' creates a lot of cluttering

[flexjoly]

Hi,
I hope I am allowed to write this here. I cannot make a real RFC or so. So I hope this is ok.

At last I have the opportunity to start using php8, I am very happy with it and how mature it has become; implementing all kinds of code quality.

But this new uninitialized state is really a pain.
When you set a property in a class, I consider it as set into the class; it is part of that class, that object.
Whether it is undefined or not. You could access it with an easy if or ternary operator.

And you got a clean overview of all your properties and how they are initialized.

class Test {

  protected string $name;

  protected string $type = 'mytype';

  protected ?array $arrLog;

  protected ?string $optionalVar;

  protected string $table = 'category';

 protected bool $isOk = false;
}

This looks clean and gives clear, easy insight to the purpose of each property.
But since php8, you have to use isset() or empty() to check whether a property is initialized.

Also php is offering more and more shorthand alternatives like nullsafe operator, ternary operator etc. Which I was not in favor of, but it seems to be the standard nowadays, so I let phpstorm do its thing and use the shorthands.

But when you start using the (very necessary!!!) typed properties this is not working anymore unless you 'initialize' the property with at least an empty or dummy value or null.
I read the RFC trying to understand.....

Maybe it is technically difficult or it is against high-standard rules (which I love!), but this is really unpractical and gives to much overhead and clutter.
I love good quality in coding, I endured years of being called crazy by colleagues who learned php by google and stackoverflow and loved it because it allowed all the bad coding. (Good is good enough)

But now it seems to go over the top, making php less practical.

For this uninitialized-thing we can choose one the following solutions at the moment:

• leave properties untyped, which is really bad
• set many properties to null or other empty values, which clutters your property list
• add those empty values inside the constructor, which creates useless extra lines of code
• use isset or empty to check if it is set or not, and not be able to use shorthands

To use typed properties and profit from all the new shorthands and nice new feature of php 8, my class has to be something like:

class Test {

  protected string $name = '';

  protected string $type = 'mytype';

  protected ?array $arrLog = [];

  protected ?string $optionalVar = null;

  protected string $table = 'category';

 protected bool $isOk = false;
}

This looks cluttered. And I do not understand that we get all those nice shorthands, but for typed properties, we need to type more....

Why does a nullable type not automaticly default to null, or even to the empty variant of the type (by giving it not an question-mark but the exclamation mark, maybe) like:

class Test {

  protected !string $name;  // defaults to ''

  protected string $type = 'mytype';

  protected !array $arrLog;  // defaults to []

  protected ?string $optionalVar;  // defaults to null

  protected string $table = 'category';

 protected !bool $isOk;  // defaults to false
 
 protected !float $someNumber;  // default to 0

 protected ?myObject $oObject;   // no default for objects... to complicated and risky, or not??, so only nullable
}

I hope this can be considered again.

Thanks in advance, flexJoly

[Girgias]

This will need an RFC, please email the internals mailing list about this proposal.

[flexjoly]

Thanks.
Never done that, but I will give it a try 😲

[heiglandreas]

From a coding point of view I understand a class as a template. It just describes how things can look like. As soon as I instantiate that class you create an actual implementation of that template. But the defined variables are so far still nothing else than a pointer to a memory allocation. When this variable is called, then check this memory area. So far this memory area does contain nothing. Or better, it might contain anything left over from some previous memory allocation. So it is not even null.

So whenever I want to use that memory-allocation, I have to make sure, that something sensible is put into it. I can do that by

• either creating the template in a way that it already contains some sensible defaults
• or by defining values during the creation of the instance in the constructor of the class.

I prefer to do that explicitly in either of those two ways over having that done magically via some fallback that will only instantiate those properties that are nullable but not others. Or are others then preset with an empty string (string-type), a 0 (int/float-type), or a false (bool-type)? And what about Objects?

I'm all in favour for being explicit.

Just my 0.02 €

[iluuu1994]

@flexjoly Thank you for your proposal! I see a thread was opened in the internals mailing list.
https://externals.io/message/119484

Unfortunately, there didn't seem to be clear consensus on what the right move is (if any) so an RFC would definitely be necessary. Thus I'm closing this issue.