Extending class with unnamed type is possible????

[gzhegow1991]

Description

The following code:

<?php

class Hello1
{
	public function helloFn(int $test = 123) // could be any int|string, not work with array|\stdClass
	{
		echo $test . PHP_EOL;
	}
}

class Hello2 extends Hello1
{
	public function helloFn($test = 'tmp')
	{
		echo $test . PHP_EOL;
	}
}

class Hello3 extends Hello2
{
	public function helloFn($test = 456)
	{
		echo $test . PHP_EOL;
	}
}

$tmp = new Hello1();
$tmp->helloFn(); // 123 (int)

$tmp = new Hello2();
$tmp->helloFn(); // tmp (string)

$tmp = new Hello3();
$tmp->helloFn(); // 456 (int)

Resulted in this output:

123
tmp
456

But I expected this output instead:

123
RuntimeException('Signature should be compatible')

PHP Version

PHP 8.0

Operating System

Win10 x64

Please explain why "removing type" is a "feature" not a "bug"

Seems its useful but conflicts with "change type is fatal".
Guess it shouldn't be fixed, but...

ADDED (works as expected, instead of example above):

class Hello1
{
	public function helloFn($test = 123)
	{
		echo $test . PHP_EOL;
	}
}

class Hello2 extends Hello1
{
	public function helloFn(int $test = 456)
	{
		echo $test . PHP_EOL;
	}
}

class Hello3 extends Hello2
{
	public function helloFn($test = 'tmp')
	{
		echo $test . PHP_EOL;
	}
}

Fatal error: Declaration of Hello2::helloFn(int $test = 456) must be compatible with Hello1::helloFn($test = 123) in /home/user/scripts/code.php on line 13

I think - criteria could become more stronger, so "adding type if missing" is allowed, changing or removing, casting is not allowed. Using extended types of previously declared have to be allowed too.

[damianwadley]

The "unnamed type", as you call it, is known as the mixed type. mixed allows all values.

In the first example, Hello1's helloFn only supports $test as an integer. To be compatible with that, Hello2 needs to support integers as well. And it does. It also supports strings and arrays and objects and anything else, but what matters is that it supports integers.
In the second example, Hello1 supports all values, which means Hello2 needs to support all values to be compatible. It does not, which is why PHP raises the fatal error.

The ability for a child method's parameters to allow more types than the parent method is called "contravariance" and is part of the Liskov substitution principles.

[gzhegow1991]

W...wait, arent you think that you understand Liskov backwards?

Is most early, base class, have to be at much more strict as possible and in same time declare limitations to all of its children?

I guess there's brainwashing between dependency inversion and liskov substitution.

Liskov substitution is about "superclass could be replaced by its descendant", so interface could be replaced with its implementation. If you declare method that expects FIGURE, its descendants should be able to use any of FIGURE or (SQUARE or CIRCLE -> both of them extends or implements FIGURE). It says nothing about "you can omit type to pass any value just because of "mixed" type allows figure too).

It seems like "parent method awaits figure, but child method can expect any object just because figure is object too"

Is the "mixed" type an implementation of "integer" type? Its reverse-thinking!

Or just maybe "extends" literally means "extend behavior" that means "more than it was", then correct...

I think "extend" means "specify" whole time before.

[damianwadley]

https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Contravariant_method_parameter_type

Similarly, it is type safe to allow an overriding method to accept a more general argument than the method in the base class:

[gzhegow1991]

Thanks

[gzhegow1991]

Ehm, it wont works with return types, why? (return type is non-extendable using that point of view)

GPT can joke me, but it says that JAVA and C# follows "more specific child" instead of PHP that follows "more wider child". Btw extend word literally means wider

In addition, argument count replacement too allowed only in __construct(), if any extended method means "it should be more wider" - all of the methods have to be fully replaceable in child (predicting parent::method() call with more specific arguments).

But we have that "method signature" is a behavior contract that becomes less specific, my brain is in-fire.

[damianwadley]

Yes, it is a little more complicated because PHP does object-oriented programming but also does scalar types.

The purpose of LSP is to make sure any code that works with a Hello1 object can also work with a Hello2 object.

abstract class Hello1 {
    // code calling this method must be able to pass an integer or a string
    public function allowsIntegerAndString(int|string $arg1) { }

    // code calling this method expects either an integer or a string
    public function returnsIntegerOrString(): int|string { ... }
}

class Hello2 extends Hello1 {
    // valid: code calling this method is able to pass an integer or a string
    public function allowsIntegerAndString(int|string|array $arg1) { }

    // valid: code calling this method will receive either an integer or a string
    public function returnsIntegerOrString(): int { ... }
}

class Hello3 extends Hello1 {
    // invalid: code calling this method is not able to pass a string
    public function allowsIntegerAndString(int $arg1) { }

    // invalid: code calling this method might receive an array
    public function returnsIntegerOrString(): int|string|array { ... }
}

function test(Hello1 $object) {
    // allowed if $object is a Hello2, is an error if $object is a Hello3
    $object->allowsIntegerAndString("a string must be valid");

    // allowed if $object is a Hello2, may be an error if $object is a Hello3
    $value = $object->returnsIntegerOrString();
    assert(gettype($value) === "integer" || gettype($value) === "string");
}