To do null-able typing or not to do null-able typing , that is a question .

[imme-emosol]

👋 Hallo,

In 00800ef some parameters that defaulted to null ( as added in 700af4b ) are changed to have their default value in the list of parameters ( instead of in the method body ) .

After seeing that , I found myself wondering why that happened , but the 🚿 commit message did not give me much insight into the reasoning behind the change . Perhaps someone here is willing to write something about the reasoning .

---

As for myself , somewhere while programming , I have come to use the practice of making optional arguments to have a default value of null and setting the type to be null able , while having the default value for the argument in the method body .

A reason for me doing so , is that it seems to more naturally prevent the information (of the default value) from being copied over into the parameters list of overriding methods ( in a inheriting class ) .

null-able params (so args too)

Make it possible to send null argument-values for optional parameters

extending method

To "demonstrate" the practice , the default value is changed to have some more information than just the empty type .

class CustomBitBuffer extends BitBuffer{
	public function __construct(array $bytes = [0 => '', 1 => null,]){
		parent::__construct($bytes);
		// do custom things
	}
}

vs.

class CustomBitBuffer extends BitBuffer{
	public function __construct(?array $bytes = null){
		parent::__construct($bytes);
		// do custom things
	}
}

---

diffs

Diff from the initial src/Common/BitBuffer.php :

-	public function __construct(array $bytes = null){
+	public function __construct(?array $bytes = null){
		$this->buffer = $bytes ?? [];
		$this->length = count($this->buffer);
	}

Diff from the current src/Common/BitBuffer.php :

-	public function __construct(array $bytes = []){
+	public function __construct(?array $bytes = null){
-		$this->buffer = $bytes;
+		$this->buffer = $bytes ?? [];
		$this->length = count($this->buffer);
	}

---

[codemasher]

Hey, a quick answer: the BitBuffer class is used only internally and i don't see a reason to be explicit about the default null value there, only to change it immediately to [] in the next line. It's a simplification for an otherwise unnecessary assignment.

I have come to use the practice of making optional arguments to have a default value of null and setting the type to be null able

In general I agree with you here, especially in case the public API. As for the internals I don't see much reason to be strict about it (you'll see several cases in the Detector/Decoder files). However, I'm not exactly a friend of the nullable type in parameter lists as it adds no value other than perhaps specifying it in the middle of mandatory parameters:

// no value here
function whatever(?string $foo = null){}

// parameter must be specified even if it is null - annoyance at best
function whatever(?string $foo){}

// the only valid use - nullable before mandatory parameter
function whatever(?string $foo, int $bar){}

What I've seen so far is a lot of the second case, perhaps because people are unaware of the fact - I don't know.

[codemasher]

On a side note: thank you for looking through the code/commits and giving feedback - much appreciated!

[imme-emosol]

Thank you for the quick reply , the explanation in it and sharing your perspective on the null able typing .

It seems best to close this discussion now , so I will do that . Guessing that it can be reopened by others , if so required .

[codemasher]

Leaving this here because it's related: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types

I guess I'll have to change it sooner or later...