> Plus, FWIW I recently decided to switch from one convention to another in every new project I happen to work on, and I comfortably obtained the suffix-less style by aliasing third party interfaces with a bunch of `use` statements. Why can't you all do the same?
If you ask seriously, you can read the discussion, but in short: * [minor issue] obviously, it is impossible to alias everything (especially when you use unpopular convention) unless PhpStorm can do it automatically (it has no such feature so far, but probably there is a plugin?); * aliasing solves very minor part of the issue, the real impact is that it forces people to think about corresponding class names, allows to change interface with class and vice versa for many consumers without BC break, sometimes it moves design in the right direction (don't create interface for no reason), etc.; On Tuesday, February 28, 2017 at 9:33:13 PM UTC+3, Stefano Torresi wrote: > > This is a non issue, please, leave this discussion alone, it has been > settled a long time ago! > > Plus, FWIW I recently decided to switch from one convention to another in > every new project I happen to work on, and I comfortably obtained the > suffix-less style by aliasing third party interfaces with a bunch of > `use` statements. Why can't you all do the same? > > We have to accept that people will always have different opinions on the > matter, and consensus is *impossible* to achieve. > > Consistency with the status-quo is a more valuable thing on the table. > > Can we just leave it at that? > > Il giorno mar 28 feb 2017 alle ore 19:16 Rivera, John <[email protected] > <javascript:>> ha scritto: > >> Hello all, >> >> I’m a new face here, and has been lurking the mailing list with interest. >> >> I decided to de-lurk because this issue has always bothered me, and I’m >> very happy to see that I’m not alone, and that it’s under discussion — >> albeit possibly long over, looking at the dates :( >> >> In my opinion (and many others that I’ve worked with), an interface >> having ‘I’ or ‘Interface in its name is an anti-pattern. This begun, I >> think, with the whole “interface all the things!” design ‘pattern' that was >> all the rage around 2010 — you know, where every single class has an >> interface, even if there would ever be one implementation of said >> interface. The ‘I’ prefix (or the ‘Interface’ suffix as we have here) arose >> because, as Phil Karlton famously said, naming things is hard. >> >> But in this situation, it shouldn’t be. If you are hard pressed to think >> up of a name for an interface that does not include ‘I’ or ‘Interface’, >> you’re most likely doing it wrong. >> >> Let’s take the Logger example from below. Let’s imagine that we’re >> implementing a Logger for the first time ever. The first thing that’d come >> to mind when one thinks of logging is probably a file-based log on the >> local filesystem. So we go forth and write up that Logger class, which >> writes to said log file. It all works, we use it all over the code (with a >> composite root and dependency injection, of course) and the stakeholders >> are happy. >> >> But then suddenly, a developer pipes up and says, “files are annoying, >> let’s log to the database!”. Brilliant! So now we want a SQL logger. Being >> good developers, we refactor the Logger class into an interface, and write >> up the FileLogger and SQLLogger implementations. >> >> And what about the rest of the code? That’s right. We only need to update >> the composite root to instantiate a SQLLogger (or a FileLogger) and pass >> that in. The rest of the object graph does not have to be updated — as far >> as it is concerned, the Logger is still the same Logger it’s always been. >> It doesn’t know, nor cares, whether it is an interface or not. >> >> As you can see, naming things should be easy here. The interface should >> tell you what it is, and the implementation should tell you what it does. >> Simple. >> >> Matthieu argued that the name should make the interface the most >> important part — I think it should strive to be the opposite — the name >> should make the interface attribute irrelevant to the object graph. >> >> John >> >> On Feb 28, 2017, at 12:32 PM, Han Hui Teoh <[email protected] >> <javascript:>> wrote: >> >> It'll be ironic if this passes. Because look at PSR-2 (and the proposed >> PSR-12), they're supposed to standardize coding style and prevent further >> endless arguments. >> >> But then FIG itself cannot / will not stick to that same philosophy? I >> hope not. >> >> On Tuesday, August 16, 2016 at 3:53:26 AM UTC+8, 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/8cef0c49-0ac2-4d71-a953-28b3cd2e2992%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/8cef0c49-0ac2-4d71-a953-28b3cd2e2992%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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/FF9DE8D1-BEDD-43A4-BB16-C3B31A4890B4%40buffalo.edu >> >> <https://groups.google.com/d/msgid/php-fig/FF9DE8D1-BEDD-43A4-BB16-C3B31A4890B4%40buffalo.edu?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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0d461f9d-a327-45db-b153-3a77d767e129%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
