Re: [PSR-11] Remove ContainerException
W dniu poniedziałek, 29 sierpnia 2016 15:24:56 UTC+2 użytkownik David Négrier napisał: > > Do you mean we should rename it to something more specific, like > EntryNotFoundExceptionInterface? > > Yes, I do. > I strongly disagree with you here. Each framework has its own hierarchy of > exceptions. Requiring an existing framework to throw an exception provided > by this PSR would likely cause breaking changes in the framework. > Have a look at Symfony for instance. The container has already a "has" and > a "get" method. Implementing PSR-11 would be a breeze (if they want to). If > however we require them to use a ContainerException "class" (instead of an > interface), that adoption could not be done before Symfony 4 (because > Symfony currently has its own NotFoundException and it cannot change it > without breaking the API). > No, if you provide for the consumers additional functionality with re-throwing non-standard exception as standard exception. Next major is enough and is must be in every case. -- 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/3cdcbafa-9d42-423a-a46e-82a0f55e8337%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PSR-11] Remove ContainerException
W dniu poniedziałek, 29 sierpnia 2016 15:24:56 UTC+2 użytkownik David Négrier napisał: > > > I'm not sure I understand your comment. Do you mean we should rename it to > something more specific, like EntryNotFoundExceptionInterface? > Yes, I do. > I strongly disagree with you here. Each framework has its own hierarchy of > exceptions. Requiring an existing framework to throw an exception provided > by this PSR would likely cause breaking changes in the framework. Have a > look at Symfony for instance. The container has already a "has" and a "get" > method. Implementing PSR-11 would be a breeze (if they want to). If however > we require them to use a ContainerException "class" (instead of an > interface), that adoption could not be done before Symfony 4 (because > Symfony currently has its own NotFoundException and it cannot change it > without breaking the API). > > I think, there is a possibility to re-throw an exception in PSR wrapper without breaking API. Next minor as a new functionality is enough. Best regards, Krzysiek. -- 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/89928e00-d6d3-4cd4-9731-f90b49cebe59%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PSR-11] Remove ContainerException
W dniu poniedziałek, 15 sierpnia 2016 21:10:07 UTC+2 użytkownik Matthieu Napoli napisał: > > 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*. > Hello, IMO both interfaces are questionable. 1. ContainerException - One interface to represents a runtime and logic exceptions so at the end we should always base on the implementation. - No clear context. - Enforces exception implementation. 2. NotFoundException - Not found what? Container was not found? - No clear context. The whole idea to use interfaces with exceptions to mark 'something' is totally impractical. If we think that something is very important we should provide the exception classes derived from standard exception hierarchy, just like we do providing PSR interfaces, because classes are just interfaces. -- KP -- 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/e6ecd732-20e7-47ac-94e0-86225f014671%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [PSR-7] Opinions requested on potential patch
In my opinion both 'self' and 'static' are for the implementors. These interfaces should be describe as always returning concrete interface. -- Krzysiek Piasecki -- 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/d1310d84-20e7-40fa-907a-985c8f57f6e0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
