Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

I like the Interface suffix. As some of them pointed, it gives more clarity that it is an interface than a concrete implementation. When you call ResponseInterface and Response how do you understand whether it is a concrete implementation or not. We should think about readability and

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

To reiterate, this change would *not* affect finalized, approved PSRs at all. It is *explicitly* only for future PSRs. For my part, I've always been annoyed by including the type of item in the name of the item itself (Interface, Trait, Controller, Model, etc), especially when the namespace

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

I disagree with removing the -Interface suffix. Not so much that I think it has to be there, but more along the lines of if it isn't going to be there then the FIG should select a new, perhaps less verbose, naming convention instead. I feel the suffix gives clarity and informs

Re: [PSR-11] Remove ContainerException

> On Aug 15, 2016, at 14:10, Matthieu Napoli wrote: > > Hi, > > PSR-11, aka ContainerInterface, has been sleeping for too long. Let's get > that PSR moving! Woohoo! > Here is a change I would like to suggest: remove the interface > ContainerException. ... > After

[Internal] Resignation - The PHP League

Dear Membership, After much internal debate we have decided that, as of today, The PHP League will be resigning as a voting member project of the FIG. This is not a reaction to any specific singular event that has happened recently, but instead due to the general trend this organization is

[Internal] Resignation - The PHP League

Dear Membership, After much internal debate we have decided that, as of today, The PHP League will be resigning as a voting member project of the FIG. This is not a reaction to any specific singular event that has happened recently, but instead due to the general trend this organization is

Re: [PSR-11] Remove ContainerException

On 8/15/16 13:13, Glenn Eggleton wrote: I believe removal of it is going to cause a lot of BC Breaks... They can't have BC breaks on something that is not standardized yet. PSR-11 is still a work in progress as far as I know. For example in Slim we do extend from *ContainerException* * *

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

I strongly support this. We took the same decision for async-interop: https://github.com/async-interop/event-loop/issues/5 How do you propose to resolve this common problem? > namespace Zend\Diactoros; > use Psr\Http\Message\ServerRequestInterface; > class ServerRequest implements

Re: [PSR-11] Remove ContainerException

I believe removal of it is going to cause a lot of BC Breaks... For example in Slim we do extend from *ContainerException* [1]: https://github.com/slimphp/Slim/blob/3.x/Slim/Exception/ContainerException.php We do actually use it.

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

How do you propose to resolve this common problem? namespace Zend\Diactoros; use Psr\Http\Message\ServerRequestInterface; class ServerRequest implements ServerRequestInterface { ... } When the class name is the same as the interface name, you have to use aliases. The correct approach for the

Re: [Discussion][Internals] Remove the Interface suffix from PSR naming conventions

Thanks for starting discussion on this. The suffix has long irked me as per the "interface being a detail" argument, so this change certainly will have my vote. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To

[Discussion][Internals] Remove the Interface suffix from PSR naming conventions

Hi all, This is a 2 weeks discussion before going to a vote. The "Interface" suffix has been questioned a few times already, I'm suggesting we put that up to a vote and avoid future debates. Here are relevant threads I could find on the topic: -

[PSR-11] Remove ContainerException

Hi, PSR-11, aka ContainerInterface, has been sleeping for too long. Let's get that PSR moving! Here is a change I would like to suggest: *remove the interface ContainerException*. After years of using container-interop and ContainerInterface I have not seen a use case for that exception. We

Re: [REVIEW] PSR-13: Link definition interfaces

> On Aug 15, 2016, at 13:34, Matthew Weier O'Phinney > wrote: > > On Mon, Aug 15, 2016 at 12:27 PM, Paul Jones wrote: >> >>> On Aug 15, 2016, at 12:22, Matthew Weier O'Phinney >>> wrote: >>> >>> Please take some time

Re: [REVIEW] PSR-13: Link definition interfaces

On Mon, Aug 15, 2016 at 12:27 PM, Paul Jones wrote: > >> On Aug 15, 2016, at 12:22, Matthew Weier O'Phinney >> wrote: >> >> Please take some time to review the proposed standard. > > Are any member projects currently doing anything that resembles

[REVIEW] PSR-13: Link definition interfaces

As coordinator of "PSR-13: Link definition interfaces", I hereby officially place the proposal in Review status. Review will end no earlier than 17:22 on 29 August 2016. The specification may be found here: - https://github.com/php-fig/fig-standards/blob/master/proposed/links.md with a

Re: [PSR-15] FrameInterface

Ok, thanks for your quick response, Woody. An yes, I admit the factory methods is a violation of SRP. But IMHO, the responsability of the stack is to execute the frames, and the DispatcherInterface example does just this (execute & move to the next), so I think there’s no violation here. The

Re: [PSR-15] FrameInterface

Hello. Maybe this is a bad idea, but just in case: Why not merge frameInterface with StackInterface in just one interface, let’s say ‘DispatcherInterface’? For example: interface DispatcherInterface { public function dispatch(RequestInterface $reques) : ResponseInterface; } interface

Re: [PSR-15] Why StackInterface? And why is it not a middleware?

Thanks Woody for your answer. Such information should be in the META document, else we are bound to discuss all this over and over. Back to the topic: I don't see how the interface helps. If I'm writing a server middleware stack, I'll type-hint against ServerMiddlewareInterface (and vice-versa

Re: [PSR-15] FrameInterface

Naming things are hard if and only if their function is hard to define I still don't see any added value in turning the $next into a formal interface. Moving on from that: NextMiddlewareInterface might be okay for a name... NextMiddlewareInterface -> process ( Request ) On Sunday,

Re: [PSR-15] FrameInterface

> > I'm comfortable with this approach. > Great. But *MiddlewareInterface* is using *process* instead of *__invoke*. Should we settle on one approach for both? Alex On Sunday, August 14, 2016 at 9:20:22 PM UTC+3, Woody Gilk wrote: > > On Sun, Aug 14, 2016 at 12:32 PM, Matthieu Napoli