PSR-13 - Evolved

[Larry Garfield]

Hi folks.

Now that we have a shiny new process for how to adapt older PSRs to modern language features, I offer up PSR-13 as a guinea pig while we work through any kinks. It's a fairly small and focused PSR so if we screw up something along the way the impact is less than if we broke, say, PSR-3 or PSR-7. :-)

The various PRs are here:

Standard:
https://github.com/php-fig/fig-standards/pull/1199

"v2":
https://github.com/php-fig/link/pull/6

"v3":
https://github.com/php-fig/link/pull/7

Feedback welcome, on both details and process.

This will require an Errata vote of the Core Committee in no less than 2 weeks. That of course puts us right up against the holiday break, so if folks want to hold off on the actual Errata vote until after New Years I'm OK with that. I just wanted to get the process kick started.

Related: There's an open PR now against link-util, from me, so I shouldn't merge it. I am not sure who else should:

https://github.com/php-fig/link-util/pull/5

Upon adoption of the new spec versions, I'll handle releasing updated versions of the util library. I am not sure if I will bother with a 2 step release or just jump straight to the final version, frankly. (Input welcome if you have strong feels.) I'll also bump the PHPUnit version at the same time (per another PR I recently closed).

--
Larry Garfield
la...@garfieldtech.com

[G. P. B.]

On Tue, 3 Dec 2019 at 01:14, Larry Garfield <la...@garfieldtech.com> wrote:

Hi folks.

Now that we have a shiny new process for how to adapt older PSRs to modern language features, I offer up PSR-13 as a guinea pig while we work through any kinks.  It's a fairly small and focused PSR so if we screw up something along the way the impact is less than if we broke, say, PSR-3 or PSR-7. :-)

The various PRs are here:

Standard:
https://github.com/php-fig/fig-standards/pull/1199

"v2":
https://github.com/php-fig/link/pull/6

"v3":
https://github.com/php-fig/link/pull/7

Feedback welcome, on both details and process.

This will require an Errata vote of the Core Committee in no less than 2 weeks.  That of course puts us right up against the holiday break, so if folks want to hold off on the actual Errata vote until after New Years I'm OK with that.  I just wanted to get the process kick started.

--
  Larry Garfield
  la...@garfieldtech.com

I've left comments on GitHub but I'll also add them here.

The addition of argument types should be tagged as 1.1, as it is fully backward compatible with 1.0 and provided the major benefit of allowing implementations to finally type argument types.

I see personally less value in the hassle of the V3 (which should be V2 due to the argument type one being tagged as 1.1.0)  because as of PHP 7.4 and the possibility of contravariant return types,

implementations can add return types to methods implementing these interfaces.

Best regards

George P. Banyard

[Guido Faecke]

As PSR-13 is stating, there is no single common hypermedia format.
Instead of trying to improve the existing one, why not create a new one
where we put all the guess-work to rest?
RPC response codes, REST response codes and everything in between has no
real standard.
I struggle every day with making up a "standard" for REST and RPC
between PHP and Java developers.
At that point we need to think about all the other consumers. Maybe I am
way off...anyway, I like the approach and would appreciate any
standardized solution.

Just adding my 2 cents...

[Larry Garfield]

Hi Guido.

I... think you're misunderstanding the goal here. PSR-13 is already approved, and has been for a few years now. It just handles hyperlinks on value objects modeling some REST/HATEOS format. Anything else is out of scope.

The goal here is simply a minor upgrade to the existing standard to leverage the better parameter/return typing support in recent PHP versions. Any other changes are out of scope. Addressing the broader question of REST workflows is definitely not something this addresses, nor should it.

--
Larry Garfield
la...@garfieldtech.com

> --
> 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/6258ac01-9b73-1d10-2057-ba21c76af994%40gmail.com.
>

[Larry Garfield]

On Mon, Dec 2, 2019, at 6:40 PM, G. P. B. wrote:

> I've left comments on GitHub but I'll also add them here.
>
> The addition of argument types should be tagged as 1.1, as it is fully
> backward compatible with 1.0 and provided the major benefit of allowing
> implementations to finally type argument types.
> I see personally less value in the hassle of the V3 (which should be V2
> due to the argument type one being tagged as 1.1.0) because as of PHP
> 7.4 and the possibility of contravariant return types,
> implementations can add return types to methods implementing these
> interfaces.
>
> Best regards
>
> George P. Banyard

They can add returns, but it's still better if the interface makes it syntactically explicit. Future implementations should be under no illusion of what they're expected to do, and the more we can put those rules into the code itself, the better.

--Larry Garfield

[Guido Faecke]

Sorry about that,

I was rushing through the lines while reading (or just had my head in
knots).
After revisiting it, I realized that you are absolutely right and I am
totally off.