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

[Hari K T]

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 understanding.

If the Interface suffix is too long, there are some other projects
following "I" prefix like IResponse .

I don't like but just a thought ;-) .

*Hari K T*

You can ring me : +91 9388 75 8821

http://harikt.com , https://github.com/harikt ,
http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT

Skype  : kthari85
Twitter : harikt

On Tue, Aug 16, 2016 at 8:44 AM, Daniel Hunsaker 
wrote:

> 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 already contains it.  I understand it
> increases clarity in some cases for what contexts a given item can be used
> in, but if the namespace does that as well (and the PSR namespace certainly
> qualifies), it just feels redundant.  But that's just my take on it.
>
> On Mon, Aug 15, 2016, 20:36 Navarr Barnier  wrote:
>
>> Can you breaking change a PSR like this?
>>
>> I don't think it's wise to do a complete reversal in a PSR like this
>> would be.
>>
>> Personally, I *just* refactored some small, unimportant projects to use
>> the suffix.
>>
>> In any way shape or form I sincerely hope you don't implement a "breaking
>> change" to a PSR like this.
>>
>>
>> On Monday, August 15, 2016 at 3:53:26 PM UTC-4, Matthieu Napoli wrote:
>>>
>>> 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:
>>>
>>> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
>>> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
>>> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
>>> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>>>
>>> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be
>>> suffixed by Interface"* from http://www.php-fig.org/
>>> bylaws/psr-naming-conventions/
>>>
>>> I do not suggest accepted PSRs are changed.
>>>
>>> Please share your reasons to vote FOR or AGAINST the change, let's
>>> debate for 2 weeks or more, and then let's have a vote to settle this.
>>>
>>> Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).
>>>
>>> ---
>>>
>>> Here are my arguments to vote FOR the change:
>>>
>>> *- the Interface suffix makes simple names very long*
>>>
>>> For example with PSR-7, here is the signature of a Slim/Zend Expressive
>>> middleware:
>>>
>>> public function __invoke(ServerRequestInterface $request, ResponseInterface 
>>> $response, callable $next) : ResponseInterface
>>>
>>> {
>>>
>>> }
>>>
>>>
>>> Compare that to:
>>>
>>> public function __invoke(ServerRequest $request, Response $response, 
>>> callable $next) : Response
>>>
>>> {
>>>
>>> }
>>>
>>>
>>> The last one is much simpler and clearer. Typing and reading the first
>>> one is a huge pain. This point applies of course to all PSRs, not just
>>> PSR-7.
>>>
>>> *- the Interface suffix makes the interface a detail and the
>>> implementation the main thing, it should be the other way around*
>>>
>>> We should care about the interface, not the implementation. Type-hinting
>>> against LoggerInterface means that "Logger" (the implementation) is still "
>>> *the* logger", and the interface is a secondary concept that we
>>> explicitly inject for decoupling.
>>> If "Logger" was the interface, it would be even more obvious that the
>>> interface is the most important part. The implementation is secondary and I
>>> don't even care how it's named. I just want a logger and that's what the
>>> interface is.
>>>
>>> Regarding the inconsistency it would create between PSRs I think it's
>>> nothing compared to what we would gain in terms of developer experience.
>>>
>>> Matthieu
>>>
>> --
>> 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/84a1442f-9a5a-42e8-ae8e-5b8be2fb6ce0%40googlegroups.com
>> 
>> .
>> For more options, visit 

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

[Daniel Hunsaker]

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 already contains it.  I understand it
increases clarity in some cases for what contexts a given item can be used
in, but if the namespace does that as well (and the PSR namespace certainly
qualifies), it just feels redundant.  But that's just my take on it.

On Mon, Aug 15, 2016, 20:36 Navarr Barnier  wrote:

> Can you breaking change a PSR like this?
>
> I don't think it's wise to do a complete reversal in a PSR like this would
> be.
>
> Personally, I *just* refactored some small, unimportant projects to use
> the suffix.
>
> In any way shape or form I sincerely hope you don't implement a "breaking
> change" to a PSR like this.
>
>
> On Monday, August 15, 2016 at 3:53:26 PM UTC-4, Matthieu Napoli wrote:
>>
>> 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:
>>
>> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
>> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
>> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
>> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>>
>> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be
>> suffixed by Interface"* from
>> http://www.php-fig.org/bylaws/psr-naming-conventions/
>>
>> I do not suggest accepted PSRs are changed.
>>
>> Please share your reasons to vote FOR or AGAINST the change, let's debate
>> for 2 weeks or more, and then let's have a vote to settle this.
>>
>> Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).
>>
>> ---
>>
>> Here are my arguments to vote FOR the change:
>>
>> *- the Interface suffix makes simple names very long*
>>
>> For example with PSR-7, here is the signature of a Slim/Zend Expressive
>> middleware:
>>
>> public function __invoke(ServerRequestInterface $request, ResponseInterface 
>> $response, callable $next) : ResponseInterface
>>
>> {
>>
>> }
>>
>>
>> Compare that to:
>>
>> public function __invoke(ServerRequest $request, Response $response, 
>> callable $next) : Response
>>
>> {
>>
>> }
>>
>>
>> The last one is much simpler and clearer. Typing and reading the first
>> one is a huge pain. This point applies of course to all PSRs, not just
>> PSR-7.
>>
>> *- the Interface suffix makes the interface a detail and the
>> implementation the main thing, it should be the other way around*
>>
>> We should care about the interface, not the implementation. Type-hinting
>> against LoggerInterface means that "Logger" (the implementation) is still "
>> *the* logger", and the interface is a secondary concept that we
>> explicitly inject for decoupling.
>> If "Logger" was the interface, it would be even more obvious that the
>> interface is the most important part. The implementation is secondary and I
>> don't even care how it's named. I just want a logger and that's what the
>> interface is.
>>
>> Regarding the inconsistency it would create between PSRs I think it's
>> nothing compared to what we would gain in terms of developer experience.
>>
>> Matthieu
>>
> --
> 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/84a1442f-9a5a-42e8-ae8e-5b8be2fb6ce0%40googlegroups.com
> 
> .
> 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/CAFjuE%2B%3D7eUG4i0jWguBUC3MYR1TbZsG-TdQsg_nacGYAd1bd1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jason Walker]

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 consumers/implementers that a
type hint is dealing with an interface and not a concrete class.

Thanks,

Jason

On Mon, Aug 15, 2016, 3:35 PM Niklas Keller 
wrote:

> 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 ServerRequestInterface { ... }
>
>
> If you really want to use the same name, just alias the PSR interface:
>
> namespace Zend\Diactoros;
>
> use Psr\Http\Message\ServerRequest as PsrServerRequest;
>
> class ServerRequest implements PsrServerRequest { ... }
>
> Requiring the interface to be aliased in each and every file it's used is
> a lot worse than having one single alias in an implementation.
>
> --
> 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/7eb5ba06-515a-41c3-bae7-9db47c41b5c4%40googlegroups.com
> 
> .
> 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/CAKjuMEE4goZuEtYZnYXm2%2B6oD7Xkgjjdp%2B06tBipaPLc0bQz3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Paul Jones]

> 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 years of using container-interop and ContainerInterface I have not seen 
> a use case for that exception. We initially added it to represent any 
> exception that could happen in a container.

On principle alone, I usually like to see a package-specific base exception 
class, so that you can catch any/every exception from a particular package. 
(Maybe that's more an unnecessary consistency on my part.)


-- 

Paul M. Jones
http://paul-m-jones.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+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/325BF45B-4638-43AA-9D6F-59BADB38C65E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Internal] Resignation - The PHP League

[greydnls]

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 taking. 
The increase in legalistic bureaucracy has taken front stage, and is 
impeding the good work that this group was set up to do. Put more bluntly, 
the FIG has become increasingly toxic in recent months, making effective 
participation nearly impossible. Further, the greater PHP community has 
become quite frustrated, left wondering why difficult decisions have not 
been made.

>From the League's perspective, it feels like the right time to step back 
and refocus our efforts on creating high quality, framework agnostic PHP 
packages. We are simply not adding nor receiving enough value from this 
group to remain a voting member of it.

To those who remain, we wish you the best of luck in the future. We know 
there is a group of you working diligently behind the noise, and we 
encourage you to continue doing so. The League certainly plans to continue 
using the standards put forth by the FIG, and where it makes sense may even 
jump in to help on specific standards that pertain to our projects.

On a house keeping note, as a result of this resignation, we will not be 
casting a vote in the secretarial elections.

-- Graham Daniels
The PHP League

-- 
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/236a14e7-ab3e-4253-b61f-e107d9e687fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Internal] Resignation - The PHP League

[greydnls]

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 taking. 
The increase in legalistic bureaucracy has taken front stage, and is 
impeding the good work that this group was set up to do. Put more bluntly, 
the FIG has become increasingly toxic in recent months, making effective 
participation nearly impossible. Further, the greater PHP community has 
become quite frustrated, left wondering why difficult decisions have not 
been made.

>From the League's perspective, it feels like the right time to step back 
and refocus our efforts on creating high quality, framework agnostic PHP 
packages. We are simply not adding nor receiving enough value from this 
group to remain a voting member of it.

To those who remain, we wish you the best of luck in the future. We know 
there is a group of you working diligently behind the noise, and we 
encourage you to continue doing so. The League certainly plans to continue 
using the standards put forth by the FIG, and where it makes sense may even 
jump in to help on specific standards that pertain to our projects.

On a house keeping note, as a result of this resignation, we will not be 
casting a vote in the secretarial elections.

-- Graham Daniels
The PHP League

-- 
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/b2365d65-2460-420b-ac9d-c02dbf799511%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Fabien Potencier]

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*
*
*
[1]: 
https://github.com/slimphp/Slim/blob/3.x/Slim/Exception/ContainerException.php

We do actually use it.

https://gist.github.com/geggleto/86d039f6f4924b416e6fb1bd1538e269

Cheers

On Monday, August 15, 2016 at 3:10:07 PM UTC-4, Matthieu Napoli wrote:

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 initially added it to
represent any exception that could happen in a container. But as far
I can I see, it's never useful, in other words it could as well be
"\Exception" and the result would be the same. Here is the original
discussion that lead to such
interface: 
https://github.com/container-interop/container-interop/issues/3#issuecomment-33133155



Here is the pull request to remove the
interface: https://github.com/php-fig/container/pull/2


Just to be clear: I am not suggesting to remove NotFoundException,
this exception is useful.

If anyone has ever seen a use case for that exception, please let me
know :)

Matthieu

--
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/8be1eb67-6144-4e11-854c-fa3b9e501988%40googlegroups.com
.
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/0931d159-e45d-b50d-f3cb-3d14211994b1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Niklas Keller]

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 ServerRequestInterface { ... }


If you really want to use the same name, just alias the PSR interface:

namespace Zend\Diactoros;

use Psr\Http\Message\ServerRequest as PsrServerRequest;

class ServerRequest implements PsrServerRequest { ... }

Requiring the interface to be aliased in each and every file it's used is a 
lot worse than having one single alias in an implementation.

-- 
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/7eb5ba06-515a-41c3-bae7-9db47c41b5c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Glenn Eggleton]

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.

https://gist.github.com/geggleto/86d039f6f4924b416e6fb1bd1538e269

Cheers

On Monday, August 15, 2016 at 3:10:07 PM UTC-4, Matthieu Napoli wrote:
>
> 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 initially added it to represent any 
> exception that could happen in a container. But as far I can I see, it's 
> never useful, in other words it could as well be "\Exception" and the 
> result would be the same. Here is the original discussion that lead to such 
> interface: 
> https://github.com/container-interop/container-interop/issues/3#issuecomment-33133155
>
> Here is the pull request to remove the interface: 
> https://github.com/php-fig/container/pull/2
>
> Just to be clear: I am not suggesting to remove NotFoundException, this 
> exception is useful.
>
> If anyone has ever seen a use case for that exception, please let me know 
> :)
>
> Matthieu
>

-- 
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/8be1eb67-6144-4e11-854c-fa3b9e501988%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Woody Gilk]

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 problem you put forward is:


use Psr\Http\Message\ServerRequestInterface as ServerRequest;
use Psr\Http\Message\ResponseInterface as Response;

public function __invoke(ServerRequest $request, Response, callable $next)
{ ... }


To wit, alias the interface in code that uses the interface if you find it
annoying.

I am strongly AGAINST this change as it results in churn for an a huge
number of projects without adding any value.

--
Woody Gilk
http://about.me/shadowhand

On Mon, Aug 15, 2016 at 2:53 PM, Matthieu Napoli 
wrote:

> 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:
>
> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>
> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be
> suffixed by Interface"* from http://www.php-fig.org/by
> laws/psr-naming-conventions/
>
> I do not suggest accepted PSRs are changed.
>
> Please share your reasons to vote FOR or AGAINST the change, let's debate
> for 2 weeks or more, and then let's have a vote to settle this.
>
> Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).
>
> ---
>
> Here are my arguments to vote FOR the change:
>
> *- the Interface suffix makes simple names very long*
>
> For example with PSR-7, here is the signature of a Slim/Zend Expressive
> middleware:
>
> public function __invoke(ServerRequestInterface $request, ResponseInterface 
> $response, callable $next) : ResponseInterface
>
> {
>
> }
>
>
> Compare that to:
>
> public function __invoke(ServerRequest $request, Response $response, callable 
> $next) : Response
>
> {
>
> }
>
>
> The last one is much simpler and clearer. Typing and reading the first one
> is a huge pain. This point applies of course to all PSRs, not just PSR-7.
>
> *- the Interface suffix makes the interface a detail and the
> implementation the main thing, it should be the other way around*
>
> We should care about the interface, not the implementation. Type-hinting
> against LoggerInterface means that "Logger" (the implementation) is still "
> *the* logger", and the interface is a secondary concept that we
> explicitly inject for decoupling.
> If "Logger" was the interface, it would be even more obvious that the
> interface is the most important part. The implementation is secondary and I
> don't even care how it's named. I just want a logger and that's what the
> interface is.
>
> Regarding the inconsistency it would create between PSRs I think it's
> nothing compared to what we would gain in terms of developer experience.
>
> Matthieu
>
> --
> 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/ms
> gid/php-fig/ea157c85-77b0-4fd4-a945-087ff1970a6c%40googlegroups.com
> 
> .
> 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/CAGOJM6K_MM98mzebXBCv7uHS%3D73vJbk4ze4oyUtWjejWF6bORA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Jeroen De Dauw]

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 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/CAMhmagBoKuW7H4AfdDOv-xji-uUbutkj00aJfghqx_r8XcbOzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthieu Napoli]

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:

- https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
- https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
- https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
- https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion

Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST be 
suffixed by Interface"* 
from http://www.php-fig.org/bylaws/psr-naming-conventions/

I do not suggest accepted PSRs are changed.

Please share your reasons to vote FOR or AGAINST the change, let's debate 
for 2 weeks or more, and then let's have a vote to settle this.

Discussion will last for at least 2 weeks (20:40 UTC on 29 August 2016).

---

Here are my arguments to vote FOR the change:

*- the Interface suffix makes simple names very long*

For example with PSR-7, here is the signature of a Slim/Zend Expressive 
middleware:

public function __invoke(ServerRequestInterface $request, ResponseInterface 
$response, callable $next) : ResponseInterface

{

}


Compare that to:

public function __invoke(ServerRequest $request, Response $response, callable 
$next) : Response

{

}


The last one is much simpler and clearer. Typing and reading the first one 
is a huge pain. This point applies of course to all PSRs, not just PSR-7.

*- the Interface suffix makes the interface a detail and the implementation 
the main thing, it should be the other way around*

We should care about the interface, not the implementation. Type-hinting 
against LoggerInterface means that "Logger" (the implementation) is still "
*the* logger", and the interface is a secondary concept that we explicitly 
inject for decoupling.
If "Logger" was the interface, it would be even more obvious that the 
interface is the most important part. The implementation is secondary and I 
don't even care how it's named. I just want a logger and that's what the 
interface is.

Regarding the inconsistency it would create between PSRs I think it's 
nothing compared to what we would gain in terms of developer experience.

Matthieu

-- 
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/ea157c85-77b0-4fd4-a945-087ff1970a6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[PSR-11] Remove ContainerException

[Matthieu Napoli]

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 initially added it to represent any 
exception that could happen in a container. But as far I can I see, it's 
never useful, in other words it could as well be "\Exception" and the 
result would be the same. Here is the original discussion that lead to such 
interface: 
https://github.com/container-interop/container-interop/issues/3#issuecomment-33133155

Here is the pull request to remove the 
interface: https://github.com/php-fig/container/pull/2

Just to be clear: I am not suggesting to remove NotFoundException, this 
exception is useful.

If anyone has ever seen a use case for that exception, please let me know :)

Matthieu

-- 
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/59dfaa6f-9cb4-49f6-8c83-d248e8567532%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Paul Jones]

> 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 to review the proposed standard.
>> 
>> Are any member projects currently doing anything that resembles the 
>> proposal?  If so, is there some copy of the research on those 
>> implementations?
> 
> Yes.
...
> sabredav, from Evert Pot, was one of
> these, as is zf-hal from the Apigility project; I suspect that Larry
> was proposing it due to a need in Drupal, but I'll deer to him to
> answer.

Nice. I think it'd be useful to have links to (or descriptions of) those in the 
meta, so there's some easy-to-access historical information available.


-- 

Paul M. Jones
http://paul-m-jones.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+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/2BDB38F3-7398-4A39-ABFD-8E9C39C7D4D3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Matthew Weier O'Phinney]

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 the proposal? 
>  If so, is there some copy of the research on those implementations?

Yes.

The original idea came from several of us who have worked on API
payloads, which often require or suggest relational links (think
HATEOAS), as well as utilities like DAV clients and servers (which are
essentially REST services). sabredav, from Evert Pot, was one of
these, as is zf-hal from the Apigility project; I suspect that Larry
was proposing it due to a need in Drupal, but I'll deer to him to
answer.

For the part of zf-hal, we already define Link and LinkCollection
instances that are not dissimilar to what is proposed here. With
shared interfaces, users could provide alternate implementations
within the entities they wish to expose via the API; Apigility would
simply need to introspect those to generate the payload.

-- 
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/

-- 
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/CAJp_myX%2BHR9gpZK5xDCCERbrqpE51Hdi%2BN1CTKn5YejVWVbhQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[REVIEW] PSR-13: Link definition interfaces

[Matthew Weier O'Phinney]

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 metadocument covering background and decisions here:

- https://github.com/php-fig/fig-standards/blob/master/proposed/links-meta.md

Please take some time to review the proposed standard.

As a reminder, during the review period, we may incorporate minor
changes, but no substantive changes. If you have a suggestion for a
substantive change, please open a thread to discuss it, so we can
determine whether we need to return to Draft status to address the
change, or whether we will choose to move forward.

Thanks in advance!

-- 
Matthew Weier O'Phinney
mweierophin...@gmail.com
https://mwop.net/

-- 
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/CAJp_myWF4kKDaKUsSymgtRzvXDXyJb%3DCepWG1X_ovp%2Bq4OtZPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Oscar Otero]

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 stack is inmutable so cannot be modified 
by any middleware, just executed. I don’t see more danger here than using a 
FrameInterface.
This is just an idea to reduce this specification to the minimum required.

---
Oscar Otero
https://oscarotero.com 




> El 15 ago 2016, a las 15:58, Woody Gilk  escribió:
> 
> Oscar, doing that would be a violation of SRP and would allow
> middleware to modify or inspect the stack. We should protect against
> mistakes by design.
> --
> Woody Gilk
> http://about.me/shadowhand
> 
> 
> On Mon, Aug 15, 2016 at 8:15 AM, Oscar Otero  wrote:
>> 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 ServerMiddlewareInterface
>> {
>>public function process(ServerRequestInterface $request,
>> DispatcherInterface $next): ResponseInterface
>> }
>> 
>> So, each time the method “dispatch” is called, the next frame is executed
>> and the response returned. So a typical middleware should be:
>> 
>> class AddFooHeader implements ServerMiddlewareInterface
>> {
>>public function process(ServerRequestInterface $request,
>> DispatcherInterface $next)
>>{
>>$response = $next->dispatch($request);
>>return $response->withHeader(‘Foo’, ‘Bar’);
>>}
>> }
>> 
>> And to execute this:
>> 
>> $response = $dispatcher->dispatch($request);
>> 
>> IMHO, It’s simpler and easier to understand.
>> 
>> 
>> And in addition to that, we could add methods to return the psr-7 factories
>> to use them inside the middleware:
>> 
>> interface DispatcherInterface
>> {
>>public function dispatch(RequestInterface $reques) : ResponseInterface;
>>public function getResponseFactory();
>>public function getStreamFactory();
>>//etc...
>> }
>> 
>> 
>> 
>> El 15 ago 2016, a las 14:35, Michael Cullum  
>> escribió:
>> 
>> Glenn & Woody,
>> 
>> Please make sure you are aware of the self-throttling rules.
>> 
>> --
>> Many thanks,
>> Michael C
>> FIG Secretary
>> 
>> On 15 August 2016 at 13:31, Glenn Eggleton  wrote:
>>> 
>>> 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, August 14, 2016 at 2:20:22 PM UTC-4, Woody Gilk wrote:
 
 On Sun, Aug 14, 2016 at 12:32 PM, Matthieu Napoli 
 wrote:
> so I wonder why we aren't using __invoke in that interface too
> 
> That's a very good idea, it might be a good middle ground:
> 
> 
> interface Next
> 
> {
> 
>public function __invoke(ServerRequestInterface $request) :
> ResponseInterface;
> 
> }
 
 I'm comfortable with this approach. The type hint would still have to
 be included, though:
 
 public function process(ServerRequestInterface $request, NextInterface
 $next)
 {
return $next($request);
 }
 
 I also don't love name NextInterface but... naming things is hard.
 --
 Woody Gilk
 http://about.me/shadowhand
 
 
 
> 
> --
> 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 post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> 
> https://groups.google.com/d/msgid/php-fig/etPan.57b0ab4a.72d7b9d0.16394%40mnapoli.fr.
> 
> 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/c025e5d9-991b-43b5-af97-3bb7df023870%40googlegroups.com.
>>> 
>>> For more options, visit https://groups.google.com/d/optout.
>> 
>> 
>> 
>> --
>> 

Re: [PSR-15] FrameInterface

[Oscar Otero]

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 ServerMiddlewareInterface
{
public function process(ServerRequestInterface $request, 
DispatcherInterface $next): ResponseInterface
}

So, each time the method “dispatch” is called, the next frame is executed and 
the response returned. So a typical middleware should be:

class AddFooHeader implements ServerMiddlewareInterface
{
public function process(ServerRequestInterface $request, 
DispatcherInterface $next)
{
$response = $next->dispatch($request);
return $response->withHeader(‘Foo’, ‘Bar’);
}
}

And to execute this:

$response = $dispatcher->dispatch($request);

IMHO, It’s simpler and easier to understand.


And in addition to that, we could add methods to return the psr-7 factories to 
use them inside the middleware:

interface DispatcherInterface
{
public function dispatch(RequestInterface $reques) : ResponseInterface;
public function getResponseFactory();
public function getStreamFactory();
//etc...
}



> El 15 ago 2016, a las 14:35, Michael Cullum  escribió:
> 
> Glenn & Woody,
> 
> Please make sure you are aware of the self-throttling rules.
> 
> --
> Many thanks,
> Michael C
> FIG Secretary
> 
> On 15 August 2016 at 13:31, Glenn Eggleton  > wrote:
> 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, August 14, 2016 at 2:20:22 PM UTC-4, Woody Gilk wrote:
> On Sun, Aug 14, 2016 at 12:32 PM, Matthieu Napoli > 
> wrote: 
> > so I wonder why we aren't using __invoke in that interface too 
> > 
> > That's a very good idea, it might be a good middle ground: 
> > 
> > 
> > interface Next 
> > 
> > { 
> > 
> > public function __invoke(ServerRequestInterface $request) : 
> > ResponseInterface; 
> > 
> > } 
> 
> I'm comfortable with this approach. The type hint would still have to 
> be included, though: 
> 
> public function process(ServerRequestInterface $request, NextInterface $next) 
> { 
> return $next($request); 
> } 
> 
> I also don't love name NextInterface but... naming things is hard. 
> -- 
> Woody Gilk 
> http://about.me/shadowhand  
> 
> 
> 
> > 
> > -- 
> > 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 post to this group, send email to php...@googlegroups.com <>. 
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/php-fig/etPan.57b0ab4a.72d7b9d0.16394%40mnapoli.fr
> >  
> > .
> >  
> > 
> > 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/c025e5d9-991b-43b5-af97-3bb7df023870%40googlegroups.com
>  
> .
> 
> 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/CAAqcDMjHWYx9Udft0uUj6EC9zbOr5d8E2vQFEgxEe5FAomF5ng%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> 

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

[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 if it's a client middleware stack). 

> it illustrates the requirement that stacks must be aware of  the type 
hint of the middleware being added to the stack [1]. If the stack  ONLY 
accepts client middleware, it MUST type hint against 
 ClientMiddlewareInterface. If it accepts both server and client 
 middleware, it MUST type hint against MiddlewareInterface. 

Right, so how is the interface helping since it's type-hinting against the 
root "MiddlewareInterface"? It will prevent implementors from type-hinting 
against a more specific interface so I don't see the point. I'm missing 
something here.

> Now it could certainly be argued that having the StackInterface is out of 
scope for the spec and I wouldn't disagree. However, any removal [2] should 
be accompanied by an update to the middleware meta document to describe how 
the type hints should be used.

What do you mean by that?

Thanks!
Matthieu

-- 
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/0337e9ae-a8a1-45c3-a84d-02b412534e37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Glenn Eggleton]

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, August 14, 2016 at 2:20:22 PM UTC-4, Woody Gilk wrote:
>
> On Sun, Aug 14, 2016 at 12:32 PM, Matthieu Napoli  > wrote: 
> > so I wonder why we aren't using __invoke in that interface too 
> > 
> > That's a very good idea, it might be a good middle ground: 
> > 
> > 
> > interface Next 
> > 
> > { 
> > 
> > public function __invoke(ServerRequestInterface $request) : 
> > ResponseInterface; 
> > 
> > } 
>
> I'm comfortable with this approach. The type hint would still have to 
> be included, though: 
>
> public function process(ServerRequestInterface $request, NextInterface 
> $next) 
> { 
> return $next($request); 
> } 
>
> I also don't love name NextInterface but... naming things is hard. 
> -- 
> Woody Gilk 
> http://about.me/shadowhand 
>
>
>
> > 
> > -- 
> > 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 post to this group, send email to php...@googlegroups.com 
> . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/php-fig/etPan.57b0ab4a.72d7b9d0.16394%40mnapoli.fr.
>  
>
> > 
> > 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/c025e5d9-991b-43b5-af97-3bb7df023870%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Alexandru Pătrănescu]

>
> 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  > wrote: 
> > so I wonder why we aren't using __invoke in that interface too 
> > 
> > That's a very good idea, it might be a good middle ground: 
> > 
> > 
> > interface Next 
> > 
> > { 
> > 
> > public function __invoke(ServerRequestInterface $request) : 
> > ResponseInterface; 
> > 
> > } 
>
> I'm comfortable with this approach. The type hint would still have to 
> be included, though: 
>
> public function process(ServerRequestInterface $request, NextInterface 
> $next) 
> { 
> return $next($request); 
> } 
>
> I also don't love name NextInterface but... naming things is hard. 
> -- 
> Woody Gilk 
> http://about.me/shadowhand 
>
>
>
> > 
> > -- 
> > 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 post to this group, send email to php...@googlegroups.com 
> . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/php-fig/etPan.57b0ab4a.72d7b9d0.16394%40mnapoli.fr.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>

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  > wrote: 
> > so I wonder why we aren't using __invoke in that interface too 
> > 
> > That's a very good idea, it might be a good middle ground: 
> > 
> > 
> > interface Next 
> > 
> > { 
> > 
> > public function __invoke(ServerRequestInterface $request) : 
> > ResponseInterface; 
> > 
> > } 
>
> I'm comfortable with this approach. The type hint would still have to 
> be included, though: 
>
> public function process(ServerRequestInterface $request, NextInterface 
> $next) 
> { 
> return $next($request); 
> } 
>
> I also don't love name NextInterface but... naming things is hard. 
> -- 
> Woody Gilk 
> http://about.me/shadowhand 
>
>
>
> > 
> > -- 
> > 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 post to this group, send email to php...@googlegroups.com 
> . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/php-fig/etPan.57b0ab4a.72d7b9d0.16394%40mnapoli.fr.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>

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  > wrote: 
> > so I wonder why we aren't using __invoke in that interface too 
> > 
> > That's a very good idea, it might be a good middle ground: 
> > 
> > 
> > interface Next 
> > 
> > { 
> > 
> > public function __invoke(ServerRequestInterface $request) : 
> > ResponseInterface; 
> > 
> > } 
>
> I'm comfortable with this approach. The type hint would still have to 
> be included, though: 
>
> public function process(ServerRequestInterface $request, NextInterface 
> $next) 
> { 
> return $next($request); 
> } 
>
> I also don't love name NextInterface but... naming things is hard. 
> -- 
> Woody Gilk 
> http://about.me/shadowhand 
>
>
>
> > 
> > -- 
> > 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 post to this group, send email to php...@googlegroups.com 
> . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/php-fig/etPan.57b0ab4a.72d7b9d0.16394%40mnapoli.fr.
>  
>
> > 
> > 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/4359293e-a51a-4225-96bf-addf4e056699%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.