>
> 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
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
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
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,
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
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
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
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
> 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
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
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*
*
*
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:
-
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
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
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
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
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.
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
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
> 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
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
21 matches
Mail list logo