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

[Woody Gilk]

On Wed, Aug 17, 2016 at 4:53 PM, Roman Tsjupa  wrote:

> It is not about being right or wrong really. Its more about being strict
> for no good reason. Its a backwards compatible change, so if you like you
> can still suffix your interfaces.
>
>
Roman, the reason FIG exists is that it takes personal choice out of the
matter and thereby provides consistency. This proposal does neither.

--
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+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/CAGOJM6KqQSZMykis%2B6676Toh7VyHL0byTTEgCPJ%2BFZioFawF7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: EventManager Draft

[Daniel Bannert]

Hey, small question,

why $argv can be a object or array in trigger($event, $target = null, $argv 
= []) when eventinterface can only take array for parm?


Am Sonntag, 20. Juli 2014 22:40:33 UTC+2 schrieb Chuck Reeves:
>
> Back at PHPTek, @crell asked if there were any ideas out there for new FIG 
> standards. I came up with the idea of having an Event Manager Interface 
> through FIG.  
>
> I took a look at Symfony, Zend Framework 2 and Doctrine to see how they 
> work then started an early draft. I made mention of it on twitter and 
> started getting some feedback.  I figured I would start a conversation here 
> to avoid the limitations of twitter and incorporate those ideas into the 
> draft.  Here is the link to what I came up with so far: 
> https://github.com/manchuck/fig-standards/blob/master/proposed/event-manager.md
>
> The 1st reaction was with the use of getName.  Symfony 3 is moving away 
> from using it in favor of using objects.   My initial thought for including 
> getName in EventInterface, was to allow implementer to build an event using 
> EventInterface and then pass that in to the EventManagerInterface::trigger 
>
> I do not know of any other frameworks use an event manager out there.  I 
> would appreciate any feedback on my initial draft as well as insight into 
> other frameworks out there that use events. 
>
> Thanks
>

-- 
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/68303946-d5bc-4018-917b-d83213c03193%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Matthieu Napoli]

Thanks a lot for the detailed response Matthew.

If you already discussed that then sorry for wasting your time (and others 
too), your answer sounds valid to me I wasn't expecting such a high level 
of backward compatibility with existing systems.

To avoid repeating that discussion in a few months I have taken the liberty 
of picking a few of your sentences and write a summary of that in the META 
document: https://github.com/php-fig/fig-standards/pull/807

Now it seems the only topic worth discussing is the name? Rasmus you 
suggested `DelegateInterface` instead of `FrameInterface`, that sounds like 
an improvement to me (I have nothing better to suggest), what do others 
think?

Le mercredi 17 août 2016 16:05:57 UTC+2, Matthew Weier O'Phinney a écrit :
>
> On Sun, Aug 14, 2016 at 12:47 PM, Larry Garfield  > wrote: 
> > On 08/14/2016 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 believe the argument MWOP made in the past is that many existing 
> > middleware systems already use __invoke(), so PSR-15 using __invoke() as 
> > well would make bridge code harder.  A separate method makes having an 
> > object that just calls the method from an existing __invoke() (or vice 
> > versa) trivial. 
>
> That was indeed the argument. 
>
> Since many (most) existing middleware systems already use either 
> callables or a class/interface that implements `__invoke()` for the 
> `$next` argument, specifying the interface within this PSR to define 
> `__invoke()` has the potential to make it completely incompatible with 
> these existing systems without major changes. 
>
> As an example, consider a middleware that targets this PSR, but is 
> dropped into Expressive or Slim, and then calls on $next: 
>
> return $next($request); 
>
> In each of these cases, a second argument *is required currently*, 
> which means that this invocation will result in a fatal error. 
>
> If we instead use another method entirely, the above becomes something 
> like: 
>
> return $frame->next($request); // or: 
> return $delegate->next($request); // or: 
> return $delegate->process($request); // etc. 
>
> As a result, these existing libraries can implement the interface 
> without breaking backwards compatibility: 
>
> class Next implements DelegateInterface 
> { 
> public function __invoke(ServerRequestInterface $request, 
> ResponseInterface $response) 
> { 
> // ... 
> } 
>
> public function next(ServerRequestInterface $request) 
> { 
> // ... 
> } 
> } 
>
> allowing them to mix-and-match middleware written for the previous 
> version with middleware targeting this PSR. Since the new interface 
> method only indicates one required argument, the implementation can 
> even pass the response to ensure backwards compatibility, and provide 
> tools for scanning middleware to warn about implementations that need 
> to be updated. 
>
> While I appreciate that we want to standardize on what is already 
> being done, the fact that the calling patterns of existing middleware 
> dispatchers vary currently means that having a discrete, unique method 
> ensures greater compatibility once the specification is finalized, 
> easing the way to adoption by existing libraries. 
>
> -- 
> Matthew Weier O'Phinney 
> mweiero...@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/8ea2fb90-2d69-484c-9b53-bec40722a17b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Paul Jones]

> On Aug 15, 2016, at 14:53, Matthieu Napoli  wrote:
> 
> 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.

"Against" (i.e., leave the Interface suffix in place.)

My impression is that the majority of member projects use the Interface suffix. 
Since we should generally be basing decisions on what the member projects 
themselves do, that's enough reason right there.

Further, since the suffix is already ensconced in a PSR, changing it now would 
put the two out-of-sync with each other, driving many future conversations 
about why it's OK in that PSR but not in others.

Having said that, if someone wants to do the research and come up with an 
actual count of which member projects use an Interface suffix, and which do 
not, I'd be open to modifying my stand depending on the results.


-- 

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/785378E1-5DDF-4E57-9683-73DD78D4502C%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-15] FrameInterface

[Matthew Weier O'Phinney]

On Sun, Aug 14, 2016 at 12:47 PM, Larry Garfield  wrote:
> On 08/14/2016 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 believe the argument MWOP made in the past is that many existing
> middleware systems already use __invoke(), so PSR-15 using __invoke() as
> well would make bridge code harder.  A separate method makes having an
> object that just calls the method from an existing __invoke() (or vice
> versa) trivial.

That was indeed the argument.

Since many (most) existing middleware systems already use either
callables or a class/interface that implements `__invoke()` for the
`$next` argument, specifying the interface within this PSR to define
`__invoke()` has the potential to make it completely incompatible with
these existing systems without major changes.

As an example, consider a middleware that targets this PSR, but is
dropped into Expressive or Slim, and then calls on $next:

return $next($request);

In each of these cases, a second argument *is required currently*,
which means that this invocation will result in a fatal error.

If we instead use another method entirely, the above becomes something like:

return $frame->next($request); // or:
return $delegate->next($request); // or:
return $delegate->process($request); // etc.

As a result, these existing libraries can implement the interface
without breaking backwards compatibility:

class Next implements DelegateInterface
{
public function __invoke(ServerRequestInterface $request,
ResponseInterface $response)
{
// ...
}

public function next(ServerRequestInterface $request)
{
// ...
}
}

allowing them to mix-and-match middleware written for the previous
version with middleware targeting this PSR. Since the new interface
method only indicates one required argument, the implementation can
even pass the response to ensure backwards compatibility, and provide
tools for scanning middleware to warn about implementations that need
to be updated.

While I appreciate that we want to standardize on what is already
being done, the fact that the calling patterns of existing middleware
dispatchers vary currently means that having a discrete, unique method
ensures greater compatibility once the specification is finalized,
easing the way to adoption by existing libraries.

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

Re: [PSR-11] Remove ContainerException

[Chuck Burgess]

Hey there Matthieu,

As a consumer of a PSR-implementing library, not only would I only
type-hint against the PSR interfaces rather than the library's elements, I
would also only type-hint against the PSR exceptions for catches.  Unless
my consumer code's catch is specifically able to deal with one specific PSR
exception (e.g. NotFoundException), then I would generally only catch
against the library's base exception, thus able to generically contain the
scenario of the library itself throwing whatever it might throw.  In this
case, I understand the feeling that having only one (specific) exception
can make a base exception seem unnecessary.  However, I think keeping it
not only allows for the convention/expectation that consumers may already
have... it also future-proofs my consumer code for when this PSR is
BC-superceded and adds more exceptions.

A less prevalent case might be the implementing library having its own
larger set of exceptions, where it won't necessarily make sense for them
all to extend/implement the one NotFoundException.  The worse alternative
there would be for the library have and throw its own... now my consumer
code has to know about them rather than staying only PSR-aware.  If the
base exception is available, the library can extend/implement from it, and
thus all library-added exceptions can be caught by catching the PSR base
exception alone.
CRB

On Aug 17, 2016 6:30 AM, "Matthieu Napoli"  wrote:

> Hi Chuck,
>
> Are you using ContainerInterface or do you plan to use it in PEAR? If so,
> in which scenario would that exception be useful?
> The goal is to collect such scenarios to see if that specific interface
> serves any purpose.
>
> You are welcome of course to create a base exception class (or interface)
> in PEAR's container package to satisfy your internal conventions.
>
> Matthieu
>
> Le Mer 17 août 2016, à 12:57, Chuck Burgess a écrit :
>
> PEAR most definitely wants to keep the package-level base exception, as it
> is a convention we always expect to be available.  We have *required* this
> for years, originally as a class in PEAR1 standards, until we came up with
> the idea of it instead being an interface while working on the PEAR2
> standards.  We were quite happy with its demonstrated benefits, which
> proved even better as an interface than a class [1], and were tickled to
> see the use of it spread into the community after we published it.
>
> We would prefer to *not* lose the base exception interface requirement.
> CRB
>
> [1] -- https://wiki.php.net/pear/rfc/pear2_exception_policy
>
> On Aug 15, 2016 7:35 PM, "Paul Jones"  wrote:
>
>
> > 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/ms
> gid/php-fig/325BF45B-4638-43AA-9D6F-59BADB38C65E%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/php-fig/_vdn5nLuPBI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CANsgjnuZ%2B-MW1Avdu67RCqKQXkEA2YUSs%
> 2BMrJqerRK3gXn6q%2BA%40mail.gmail.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 

Re: [PSR-11] Remove ContainerException

[David Négrier]

Hey Chuck,

PEAR FAQ says:

> By implementing the base package exception interface, all exceptions for
a given pear package can be caught with catch (\PEAR2\PackageName\Exception
$e).

But in PSR-11, there is only one (useful) exception interface:
NotFoundException.

Aknowledging the fact there is only one (and will be only one) useful
exception interface for this package, does it still make sense to keep the
base exception interface?

David.



Le mer. 17 août 2016 à 12:57, Chuck Burgess  a écrit :

> PEAR most definitely wants to keep the package-level base exception, as it
> is a convention we always expect to be available.  We have *required* this
> for years, originally as a class in PEAR1 standards, until we came up with
> the idea of it instead being an interface while working on the PEAR2
> standards.  We were quite happy with its demonstrated benefits, which
> proved even better as an interface than a class [1], and were tickled to
> see the use of it spread into the community after we published it.
>
> We would prefer to *not* lose the base exception interface requirement.
> CRB
>
> [1] -- https://wiki.php.net/pear/rfc/pear2_exception_policy
>
> On Aug 15, 2016 7:35 PM, "Paul Jones"  wrote:
>
>>
>> > 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.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/php-fig/_vdn5nLuPBI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CANsgjnuZ%2B-MW1Avdu67RCqKQXkEA2YUSs%2BMrJqerRK3gXn6q%2BA%40mail.gmail.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/CABAasbd7c4Z79jY0XDf3gDDG8JKu-h7ODeWggUkuP3kygqx-8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Matthieu Napoli]

Hi Chuck,

Are you using ContainerInterface or do you plan to use it in PEAR? If
so, in which scenario would that exception be useful?
The goal is to collect such scenarios to see if that specific interface
serves any purpose.

You are welcome of course to create a base exception class (or
interface) in PEAR's container package to satisfy your internal
conventions.

Matthieu

Le Mer 17 août 2016, à 12:57, Chuck Burgess a écrit :
> PEAR most definitely wants to keep the package-level base exception,
> as it is a convention we always expect to be available.  We have
> *required* this for years, originally as a class in PEAR1 standards,
> until we came up with the idea of it instead being an interface while
> working on the PEAR2 standards.  We were quite happy with its
> demonstrated benefits, which proved even better as an interface than a
> class [1], and were tickled to see the use of it spread into the
> community after we published it.
> We would prefer to *not* lose the base exception interface
> requirement.
>  CRB
> [1] -- https://wiki.php.net/pear/rfc/pear2_exception_policy
>
> On Aug 15, 2016 7:35 PM, "Paul Jones"  wrote:
>>
>> > 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[1].
>>  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.
>
> --
>  You received this message because you are subscribed to a topic in
>  the Google Groups "PHP Framework Interoperability Group" group.
>  To unsubscribe from this topic, visit
>  https://groups.google.com/d/topic/php-fig/_vdn5nLuPBI/unsubscribe.
>  To unsubscribe from this group and all its topics, 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/CANsgjnuZ%2B-MW1Avdu67RCqKQXkEA2YUSs%2BMrJqerRK3gXn6q%2BA%40mail.gmail.com[2].
>  For more options, visit https://groups.google.com/d/optout.


Links:

  1. mailto:php-fig%2bunsubscr...@googlegroups.com
  2. 
https://groups.google.com/d/msgid/php-fig/CANsgjnuZ%2B-MW1Avdu67RCqKQXkEA2YUSs%2BMrJqerRK3gXn6q%2BA%40mail.gmail.com?utm_medium=email_source=footer

-- 
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/1471433444.1345100.697863737.35716C31%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.