> As some of them pointed, it gives more clarity that it is an interface than a concrete implementation
Ironically, I think this is disadvantage: you don't need to know about it. Further, if you don't allow inheritance like this: final class Logger, you would be allowed to convert Logger into an interface without breaking BC. Also, you wouldn't be allowed to have poor naming like Foo implements FooInterface. It looks like naming impotence: you have implementation, why you can't describe what makes this implementation specific: MySqlFoo? MemcachedFoo? ZendFoo? And it also force to think about architecture more: if you really think that your implementation is very-very generic, are you sure that you need an interface? It would be nice to hear about advantages of the -Interface suffix. I don't see any yet. On Tuesday, August 16, 2016 at 8:04:27 AM UTC+3, Hari K T wrote: > > 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 <danhu...@gmail.com > <javascript:>> 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 <nav...@gtaero.net >> <javascript:>> 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+u...@googlegroups.com <javascript:>. >>> To post to this group, send email to php...@googlegroups.com >>> <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/php-fig/84a1442f-9a5a-42e8-ae8e-5b8be2fb6ce0%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/php-fig/84a1442f-9a5a-42e8-ae8e-5b8be2fb6ce0%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> 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+u...@googlegroups.com <javascript:>. >> To post to this group, send email to php...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/CAFjuE%2B%3D7eUG4i0jWguBUC3MYR1TbZsG-TdQsg_nacGYAd1bd1A%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/php-fig/CAFjuE%2B%3D7eUG4i0jWguBUC3MYR1TbZsG-TdQsg_nacGYAd1bd1A%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> 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/eb3432dd-b2a5-4f90-9cf0-025946cdfefb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
