Then maybe we have to ask ourselves.. Is it worth all the trouble just
to add a few type hints?
Maybe it's best to delay any such changes until PHP 7.2 is out, and then
new PSR versions could be released like psr/log 1.1.0 could be released
that requires PHP 7.2, and adds type hints.
As it seems 7.2 allows interface widening any library requiring PHP 7.2+
could start requiring psr/log ^1.1 and implement the interfaces with the
type hints, while other libraries requiring ^1.0.0 would remain
compatible with 1.1.0. That way if you require any library that require
1.1 then you have to upgrade but you need to run at least PHP 7.2.
Best,
Jordi
On 2017-04-12 13:57 PM, Michael Mayer wrote:
On Wednesday, April 12, 2017 at 1:18:48 PM UTC+2, Jordi Boggiano wrote:
Same here. Especially as the way I see it, PSR v2's will really mostly
be a thing as the library ecosystem transitions to PHP7, because of the
added scalar hints.
The benefit of migration because of scalar type declarations is
extremely minor, especially in an established TDD process.
Sure it will take some time for everything to migrate over, and it
might
lead to small periods of incompatibilities/dependency resolution
conflicts along the way.
fool/echolog <https://packagist.org/packages/fool/echolog>, for example,
still requires psr/log:1.0.0 (not ~1.0 or similar!), which makes it
unusable at the moment.
There is a PR
<https://bitbucket.org/fool/echolog/pull-requests/2/expanded-psr-log-compatibility/diff>,
which is older than a half year. Well, that can be considered as a bug,
but it is still not fixed.
But, what amount of time are we talking about? If we consider PSR-7,
then we have more than thousand packages (solely at packagist!) which
dependent on it.
Doing a BC by adding scalar type declarations (and doing a major version
bump) will bring us years of dependency hell.
PSR interfaces are not ordinary packages. Those interfaces were created
to accomplish compatibility between projects, therefore a BC is a no go.
Once we are through though we will be in a much
more desirable outcome than if we have \V2 namespaces or whatever other
similar hack.
Indeed, V2 is really bad.
--
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+unsubscr...@googlegroups.com
<mailto:php-fig+unsubscr...@googlegroups.com>.
To post to this group, send email to php-fig@googlegroups.com
<mailto:php-fig@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/663d53aa-25f5-4d1c-b07d-5ded1d8912ce%40googlegroups.com
<https://groups.google.com/d/msgid/php-fig/663d53aa-25f5-4d1c-b07d-5ded1d8912ce%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Jordi Boggiano
@seldaek - http://seld.be
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/083df612-8305-9205-0ef5-a85ab07e51f7%40seld.be.
For more options, visit https://groups.google.com/d/optout.
