PSR-11 — interface evolution

[Matthew Weier O'Phinney]

Per the discussions started earlier this year, I've opened two pull requests to "evolve" the PSR-11 ContainerInterface to use explicit type hints:

The first — https://github.com/php-fig/container/pull/27 — updates the psr/container package to require PHP 7.2, and adds the `string` typehint to the `$id` parameters of each of the `has()` and `get()` methods. The intention is for this to be tagged as v2.0, and would allow implementations:

- Immediate forwards compatibility, as the covariance/contravariance rules of PHP 7.2 allow implementations to accept wider type ranges for parameters.

- The ability to make themselves forwards compatible with a later release by adding return type hints, as this is be covered by the same covariance/contravariance rules (implementations can return a narrower set of types than their parent types).

The second — https://github.com/php-fig/container/pull/28 — builds on the previous, and updates the psr/container package to add a return type of `bool` to the `ContainerInterface::has()` method. The intention is for this to be tagged as v3.0.

These changes follow the specification verbatim, as the `$id` arguments are documented as strings. Further, I do not think this is a place where the proposed `Stringable` interface for PHP 8 comes into play; the context when pulling from a service container is generally to provide either a class name or a string service name; using a class to represent that is a sufficiently edge case that I see no good argument to wait for PHP 8 so we can do `string|Stringable` in this particular specification.

Finally, I have not proposed a return typehint for `get()`, as the specification as written explicitly allows `mixed`. Not having a return type is the technically correct approach in this context.

If there are no objections, I'd like to get these moved forward.

Thanks!

--

Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

he/him

[Larry Garfield]

This all makes sense to me, and the PRs look good.

The one note I'd have is that an explicit `mixed` type hint is probably going up for vote for PHP 8 very soon; I don't know if that justifies waiting on that for the second PR/3.0 release. For "mixed" probably not as it doesn't really offer much, but I mention it for completeness.

--Larry Garfield

[Alessandro Lai]

Mixed will be in PHP 8: https://wiki.php.net/rfc/mixed_type_v2

Also: Matthew, why the first release would be 2.0? Can't we declare it a 1.1 to make the transition smoother, as suggested by the bylaw?

[Matthew Weier O'Phinney]

On Thu, Jun 18, 2020 at 1:17 AM Alessandro Lai <alessand...@gmail.com> wrote:

Mixed will be in PHP 8: https://wiki.php.net/rfc/mixed_type_v2

Also: Matthew, why the first release would be 2.0? Can't we declare it a 1.1 to make the transition smoother, as suggested by the bylaw?

I got confused on that by Larry's blogpost, but you're absolutely correct.

I've updated the PRs such that the first one now targets a v1.1.0, and the second 2.0.0.

I tend to agree with Larry that waiting for PHP 8 for the "mixed" type doesn't offer much, and since implementations can add it without breaking compatibility, I'd rather we move forward. If nothing else, but to demonstrate PSR evolutions concretely. :)

 

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/de471524-60de-4f44-a28d-6bacff46ad32o%40googlegroups.com.

[Larry Garfield]

On Thu, Jun 18, 2020, at 2:05 PM, Matthew Weier O'Phinney wrote:

> > Also: Matthew, why the first release would be 2.0? Can't we declare it a 1.1 to make the transition smoother, as suggested by the bylaw?
>
> I got confused on that by Larry's blogpost, but you're absolutely correct.

Per both bylaw and blog post, both 1.1 and 2.0 are valid approaches depending on the details. In this case it would mainly depend on whether we consider changing from docblock "string" to type definition "string", which does technically now prevent stringable objects when they probably worked before, an API break.

That's a case-by-case question we get to sort out. I agree with MWOP that in this case no one has any damned business using a stringable object here to begin with, so it's not really a BC break in any meaningful sense. So, either way could work.

MWOP: remember to also make a PR for the PSR itself to note the change in errata. I think the PSR-13 PR had something you could steal from.

--Larry Garfield

[Matthew Weier O'Phinney]

Done:

- https://github.com/php-fig/fig-standards/pull/1215