"Just put the types in docblocks" is unfortunately insufficient. Exhibit A: PSR-6 specified a method that needed a date time, and would accept either DateTime or DateTimeImmutable, aka would take DateTimeInterface from PHP 5.5. At the time we decided to make it a docblock-only type to allow PHP 5.4 and 5.3 compatibility, which unfortunately means there are now PSR-6 implementations that handle the error case (someone passing an int timestamp, for instance) in different ways.
It's not the happy-path, but handling of error conditions is absolutely an important and relevant part of a specification. See also: the HTML5 spec is 80% documenting error handling conditions for the first time by retconning all the different things browsers ended up doing. :-) My proposal: "A spec SHOULD target a minimum version of the oldest supported PHP version at time of release. It MAY target an earlier or later version if functionality in those later versions would offer substantial benefit. It MUST NOT target a PHP version that no longer receives security support." That implies: 1) We still have wiggle-room for individual specs as appropriate that can be sorted out by each WG and the CC. 2) It makes it clear that by default we support what PHP-Internals support, so we have a "default position" to fall back on in case of irreconcilable disagreement. 3) Would currently imply "target 7.0 unless there's a very good reason otherwise." 4) A year from now would imply "target 7.1 unless there's a very good reason otherwise." 5) Gives us one more year of "you can target 5.6 if you really really need to", but: 6) Gives a very clear EOL for PHP versions that a spec will target. 7) Since as noted most languages features don't actually matter to interfaces, it's entirely possible that a 7.2-targeting spec will still be compatible with 7.0. That's totally fine if it happens; there's no reason to actively break support without cause. But "don't use iterable, that would break 7.0 compatibility" would not be a valid argument. (It *is* a valid argument today, but it wouldn't be in 2 years, and we know that ~2 years in advance.) *dons flame retardant suit* --Larry Garfield On 10/29/2017 01:46 AM, Xedin Unknown wrote: > That's, actually, my point. Because in coding terms standards are just > interfaces, it takes a very small amount of effort to make them > compatible. If, instead of type-hinting scalars, you just specify the > right types in the docs, that is enough to make a standard. PHP 7 > implementations are free to type-hint in the code, if they need, but > this doesn't make the standards themselves worse by any means. > > Also, I agree with you that the majority of WordPress developers are > not using PSR, but I am, and I would argue that a lot of devs are > moving to PHP 5.6. In fact, Joost de Valk has created a whole movement > <https://yoast.com/whipping-your-hosting-into-shape/>, pushing other > devs to switch. I try to do my best to make platform-agnostic > packages, and therefore it's kind of important that WP devs have the > possibility of writing PSR-compatible code. > > On Wednesday, October 25, 2017 at 6:13:54 PM UTC+2, Sara Golemon wrote: > > On Saturday, October 21, 2017 at 4:19:20 PM UTC-4, Tobias Nyholm > wrote: > > While reviewing PSR-18 I found a suggestion to make our base > exception to implement \Throwable. So, should new PSRs support > PHP 7 only or do we still need PHP 5 support? > > Like someone said, "PHP5 is dying, just kill it already". I > like to agree with that. But at the same time, I do not what > the guzzle/buzz community to choose between implementing this > PSR or supporting PHP5. > > I would like the core committee to give me (and other authors > of new PSRs) a unified recommendation: Should new PSRs support > PHP5 or not? > > > Given that PSRs packages are just interfaces, the problem space > comes down to type hinting and that’s basically it. There’s no > need for an interface only file to have a declare(strict_types); > declaration since it has no effect on a file with no real code. > The nature of exceptions (implements \Throwable versus extends > \Exception) falls on the edge of the type hinting issue. > > > So the question is: How much do we want scalar type hinting (and > return type hinting, throwable, iterable) in PSRs? Do we want > these things enough to exclude PHP 5 consumers? More to the point, > who is our real audience? I don’t think our audience is WordPress > (still defining their minimum version as 5.2.5). Is our audience a > bunch of green fielders who are pulling in Symfony 4 (which > requires 7.1+) ? > > > My hot take is to generally agree with Larry (7.0+ is reasonable > where there's a demonstrable benefit, but 7.1 borders on > aggressive). I don't quite agree that it's /too/ aggressive, but > it should be tempered by some degree of conservatism. > > Personally, I'd like to hear from project reps. What are your > various positions on minimum versions? > > -Sara > > -- > 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/a67e9ae8-506c-49ce-842e-45f5e3617d40%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/a67e9ae8-506c-49ce-842e-45f5e3617d40%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- 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/da3440c1-213f-3307-5918-058d78447796%40garfieldtech.com. For more options, visit https://groups.google.com/d/optout.
