Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[5.0] Add parameter type-hints #32179

Copy link
Copy link
Closed
Closed
Copy link
@derrabus

Description

@derrabus
Issue body actions

The current master branch (which will become Symfony 5) raised the minimum requirement of php to 7.2. That php version introduced a feature called Parameter Type Widening that allows a class to drop parameter type constraints when overriding/implementing a method from a parent class/interface.

This opens up an interesting upgrade path for us: We can add new type-hints to interfaces without breaking implementations that were written against the non-typed version on that interface.

Things to watch out for:

  • Start with interfaces and classes without parent.
  • Don't add type-hints to contracts interfaces: we need php 7.1 compatibility here!
  • You can only add type-hints, not change or remove existing ones.
  • Don't add return types. They require a different strategy.
  • Consult the docblock to find out if you can add a type-hint. But keep in mind that the docblock might lie to you.
  • Adding a type-hint might break code that calls the method: Have a look at the implementations of the interface and their tests to find out what kind of values can be passed to the method right now.
  • Check if null is a valid value. That case is often forgotten in type-hints.
  • Adding a callable type-hint triggers autoloading if the passed value contains a class reference as string. This is a side-effect that should be considered.
  • The method might contain now-obsolete type-checks. You may remove them.
  • The added type-hints might obsolete @param annotations. Remove them if they only contain information that is already reflected by the type-hint and the parameter name.
  • If you find an implementation or child class that is part of another component, don't upgrade the signature just yet if that components should remain compatible with the 4.4 version of the component you're currently working on.

In order to keep the changes reviewable, we should iterate over the components and open one PR per package.

Components

Bundles

Bridges

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.