Implement Parameter Type Widening RFC #2265

kelunik · 2017-01-01T13:48:26Z

See https://wiki.php.net/rfc/parameter-no-type-variance.

php-pulls · 2017-01-01T14:44:34Z

Comment on behalf of krakjoe at php.net:

labelling

kelunik · 2017-01-15T12:43:44Z

Rebase onto current master with the type changes, the test failure is unrelated.

skie · 2017-01-15T21:32:19Z

Of course, send SOLID to hell. Who is Barbara Liskov??? Some mad woman? Of course! Let's allow to break this principles and ideas!

nikic · 2017-01-15T22:05:56Z

Zend/zend_inheritance.c

+	}
+
+	if (!ZEND_TYPE_IS_SET(proto_arg_info->type)) {
+		/* Child defines a type, but parent doesn't, violates LSP */


I think it would be more intuitive to move this these checks into the argument checking code, rather than have it in the code that is shared between argument and return types. It works either way because return type checking only invokes the function if both types are set, but it's a bit confusing.

Dunno, it's the place where it was before, so I left it there.

This requires decoupling into argument check and return type check, otherwise we'll be allowing widening at return types (basically adding contra-variance support), which is not desired.
Return types only support co-variance.
Argument types only support contra-variance.

I'll add test cases to check that it doesn't allow contravariant return types and modify as needed.

nikic · 2017-01-15T22:16:48Z

@skie If you're wondering why everyone is confused about your comment: The Liskov substitution principle explicitly allows contravariance on method argument types, which is what is being implemented here. The previous implementation was too restrictive, forbidding some cases that were perfectly valid under LSP.

b1rdex · 2017-01-16T04:42:33Z

@nikic sure, contravariance must be allowed. But how did complete removing of type hint became possible and accepted?

b1rdex · 2017-01-16T05:01:49Z

@kelunik your arguments in rfc are totally mad. Enforcing type hint on method signature is breaking change and library must define new major version in this case. Depended libraries must upgrade extending/usages code and then define new self major version. That's how it must work in semver with bc-compability in mind.
Don't know why would you change language to permit totally wrong use case.

kelunik · 2017-01-16T07:09:16Z

@b1rdex No, it's not a breaking change if your code documented the accepted types before and did these checks manually.

b1rdex · 2017-01-16T07:10:48Z

Changing signature is always breaking change.

…

On Jan 16, 2017 17:09, "Niklas Keller" ***@***.***> wrote: @b1rdex <https://github.com/b1rdex> No, it's not a breaking change if your code documented the accepted types before and did these checks manually. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2265 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATGF500dHYhFD6SB0IzsnR583CUoJ_pks5rSxe1gaJpZM4LYtl-> .

kelunik · 2017-01-16T07:12:20Z

Please explain where it breaks.

nikic · 2017-01-16T14:20:20Z

@b1rdex It may help you to think of removing a type as specifying a (non-existing) mixed type instead, where mixed is the type semilattice supremum. As such, it is always contravariant (pretty much by definition).

b1rdex · 2017-01-16T14:36:04Z

@nikic good catch.

For anyone interested: following snippet is valid in Java 😮 tested with https://www.compilejava.net/

public class Foo {
    public Foo testParentClass(int $foo) {return new Foo();}
}
public class Bar extends Foo {
    public int testParentClass(String $foo) {return 2;}
}

b1rdex · 2017-01-16T14:39:26Z

@kelunik

Changing signature is always breaking change.
Please explain where it breaks.

in php changing type hints on public api will break extenders before this got merged :)

nikic · 2017-01-16T14:39:36Z

@b1rdex The Java case is somewhat different, because it's not overriding the method, but adding an overload with a different signature. In languages with method overloading variance considerations usually only come in for generic parameters and return types.

b1rdex · 2017-01-16T14:44:53Z

@nikic shame on me, I totally forgot about polymorphism… Hope php will see it someday.

kelunik · 2017-01-16T15:18:19Z

@b1rdex I don't think method overloading is something we'll see in PHP, at least not in the near future. It's rather complicated with weak types and comes with significant overhead IIRC.

in php changing type hints on public api will break extenders before this got merged :)

Changing a type declaration in a subclass will still not be allowed. The only thing that's allowed is the parent having a restriction and the child not having one, thus accepting the same thing the parent accepted and more.
Being able to upgrade existing type hints in docblocks + manual exceptions to use type declarations without breaking backwards compatibility is an important part to move forward with stricter typing.
It didn't break before, it "just" emitted a warning, because PHP can't verify co- / contravariance at compile time currently, because type declarations do not invoke the autoloader. And we don't have method overloading. So all we can do is allowing co- / contravariance instead of method overloading.

artemzakholodilo · 2017-02-02T09:36:10Z

`abstract class Person
{
private $name;

public function setName($name)
{
    $this->name = $name;
}

public function getName()
{
    return $this->name;
}

protected function __toString()
{
    
}

}

class Foo
{
public function sayHi(Person $person)
{
echo "Hi " . $person->getName();
}
}

class Human extends Person
{}

$foo = new Foo();
$foo->sayHi('Artem');
`

What about this?

schnittstabil · 2017-02-02T10:03:05Z

@artemzakholodilo This PR won't affect your example; $foo->sayHi('Artem'); stills fails, because 'Artem' is not a Person instance:

Warning: The magic method __toString() must have public visibility and cannot be static […]

Fatal error: Uncaught TypeError:
Argument 1 passed to Foo::sayHi() must be an instance of Person, string given, […]

Stack trace:
#0 […].php(34): Foo->sayHi('Artem')
#1 {main}
  thrown in […]

kelunik · 2017-02-03T21:52:41Z

@guilhermeblanco @nikic I've improved the implementation to use a separate function for args that does the additional checks. I've added an assertion to the current function, so it's only called if both types are set.

nikic · 2017-02-03T22:05:19Z

Zend/zend_inheritance.c

+	if (!ZEND_TYPE_IS_SET(proto_arg_info->type)) {
+	    /* Child defines a type, but parent doesn't, violates LSP */
+	    return 0;
+	}


nit: Some space (instead of tab) indents in the above blocks

Should I put them into a separate commit? The rest of the file already has trimmed whitespace on empty lines.

As this is newly introduced code, it should be in the same commit.

Sorry, misunderstanding. I was referring to use of 4-space indentation instead of tabs in the lines above, not the the removal of trailing whitespace, that's fine.

Ah, right, fixed. I didn't fix the other places using spaces that are not new code.

bwoebi · 2017-02-04T12:45:54Z

Zend/zend_inheritance.c

-		/* Only one has a type declaration and the other one doesn't */
-		return 0;
-	}
+	ZEND_ASSERT(ZEND_TYPE_IS_SET(fe_arg_info->type) && ZEND_TYPE_IS_SET(fe_arg_info->type));


must be proto_arg_info->type once

Good catch, fixed.

nikic · 2017-02-04T22:36:20Z

Merged via 2edc3cf with an UPGRADING note. Thanks!

JuJuDropThor · 2017-05-22T07:09:09Z

Are you mad ? Why do you want to violate SOLID and Liskus Substitution like that ? Do you really think that kind of thing will improve the reputation of PHP ?

Shame.

kelunik · 2017-05-22T07:20:54Z

@JuJuDropThor This does not violate the Liskov substitution principle (LSP).

JuJuDropThor · 2017-05-22T07:26:21Z

So could you tell me, please, how that could be possible if you change declaration of your method between a type and a subtype ?

kelunik · 2017-05-22T07:34:03Z

Sure, it's called contravariance for method argument types: https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)#Contravariant_method_argument_type

JuJuDropThor · 2017-05-22T11:55:30Z

Oh array covariance, great...

You have an array parameter:
public function foo(array $foo)

In the subclass, you could have... everything you want.
public function foo($foo)

Your subclass EverythingClass can't be replaced by an object of type ArrayClass without violating LSP.

First line of the wiki you linked:
Many programming language type systems support subtyping. For instance, if Cat is subtype of Animal, then an expression of type Cat can be used whenever an expression of type Animal could. Variance refers to how subtyping between more complex types (list of Cats versus list of Animals, function returning Cat versus function returning Animal, ...) relates to subtyping between their components.

Well, do as you wish, that RFC is validated anyway. That kind of thing doesn't honor PHP repuration.

pmmaga · 2017-05-22T12:16:56Z

In this case the contravariance is not the example you mentioned but exactly the other way around. Assuming your EverythngClass, ArrayClass example, and that ArrayClass is the parent and EverythingClass is the child, EverythingClass can replace ArrayClass without breaking LSP. In the example you are giving, you are trying to use the parent to replace the child which is not valid.

kelunik · 2017-05-22T12:18:13Z

Right, an EverythingClass can't be replaced with an ArrayClass, because that's the wrong way round. EverythingClass is the subtype, not the parent type. Anything that accepts an ArrayClass also works perfectly fine with an EverythingClass, because EverythingClass handles arrays just fine, but also everything else.

kelunik force-pushed the parameter-no-type-variance branch from a9ed7c8 to a7a682a Compare January 1, 2017 14:25

php-pulls added the RFC label Jan 1, 2017

kelunik force-pushed the parameter-no-type-variance branch 2 times, most recently from 16d2400 to 6dce990 Compare January 1, 2017 16:33

kelunik changed the title ~~Implement Parameter No Type Variance RFC~~ Implement Parameter Type Widening RFC Jan 13, 2017

kelunik force-pushed the parameter-no-type-variance branch 5 times, most recently from 430f972 to 2e85f21 Compare January 15, 2017 11:48

nikic reviewed Jan 15, 2017

View reviewed changes

kelunik force-pushed the parameter-no-type-variance branch from 2e85f21 to 5874be7 Compare January 17, 2017 15:10

kelunik force-pushed the parameter-no-type-variance branch from 5874be7 to c419e8f Compare February 3, 2017 21:50

nikic reviewed Feb 3, 2017

View reviewed changes

nikic self-assigned this Feb 3, 2017

kelunik force-pushed the parameter-no-type-variance branch from c419e8f to 2da1079 Compare February 3, 2017 22:21

bwoebi reviewed Feb 4, 2017

View reviewed changes

Implement Parameter Type Widening RFC

6a95578

kelunik force-pushed the parameter-no-type-variance branch from 2da1079 to 6a95578 Compare February 4, 2017 14:05

nikic closed this Feb 4, 2017

This was referenced Feb 5, 2017

Update PSR-15 proposal with current consensus php-fig/fig-standards#867

Merged

__invoke and parameter type widening http-interop/http-middleware#64

Closed

Incorporate feedback on http-middleware php-fig/fig-standards#878

Merged

greg0ire mentioned this pull request Feb 19, 2017

Add type hinting sonata-project/cache#65

Merged

kelunik deleted the parameter-no-type-variance branch May 22, 2017 07:12

php locked and limited conversation to collaborators May 22, 2017

Implement Parameter Type Widening RFC #2265

Implement Parameter Type Widening RFC #2265

Conversation

kelunik commented Jan 1, 2017 • edited Loading

php-pulls commented Jan 1, 2017

kelunik commented Jan 15, 2017

skie commented Jan 15, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guilhermeblanco Jan 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikic commented Jan 15, 2017

b1rdex commented Jan 16, 2017

b1rdex commented Jan 16, 2017

kelunik commented Jan 16, 2017

b1rdex commented Jan 16, 2017 via email

kelunik commented Jan 16, 2017

nikic commented Jan 16, 2017

b1rdex commented Jan 16, 2017

b1rdex commented Jan 16, 2017 • edited Loading

nikic commented Jan 16, 2017

b1rdex commented Jan 16, 2017

kelunik commented Jan 16, 2017

artemzakholodilo commented Feb 2, 2017 • edited Loading

schnittstabil commented Feb 2, 2017 • edited Loading

kelunik commented Feb 3, 2017

nikic Feb 3, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikic commented Feb 4, 2017

JuJuDropThor commented May 22, 2017

kelunik commented May 22, 2017

JuJuDropThor commented May 22, 2017

kelunik commented May 22, 2017 • edited Loading

JuJuDropThor commented May 22, 2017

pmmaga commented May 22, 2017

kelunik commented May 22, 2017 • edited Loading

kelunik commented Jan 1, 2017 •

edited

Loading

guilhermeblanco Jan 16, 2017 •

edited

Loading

b1rdex commented Jan 16, 2017 •

edited

Loading

artemzakholodilo commented Feb 2, 2017 •

edited

Loading

schnittstabil commented Feb 2, 2017 •

edited

Loading

nikic Feb 3, 2017 •

edited

Loading

kelunik commented May 22, 2017 •

edited

Loading

kelunik commented May 22, 2017 •

edited

Loading