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

I mean, converting class into interface or vice versa is regular operation in my codebase, and it doesn't make huge diff: using of a contract is just the same. On Friday, December 6, 2019 at 2:27:35 AM UTC+3, Daniel Plainview wrote: > > > I saw this being said above by Daniel Plainview: > > You

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

> I saw this being said above by Daniel Plainview: > You would still break BC for anyone who instantiates the Logger class. True, but it breaks potentially less amount of code. For example, it's a common to use bundles that instantiate services. So these bundles may keep BC, but code which just

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

I vote against. As I see, not all understand as it's work :( for example get_class() return base original class name. понедельник, 15 августа 2016 г., 22:53:26 UTC+3 пользователь Matthieu Napoli написал: > > Hi all, > > This is a 2 weeks discussion before going to a vote. > > The "Interface"

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

This is an interesting discussion. I could imagine an ideal world where "Response" is the interface name, and "SimeKindOfResponse" is a specific implementation / class. In such an utopia, if you see a "Response" as a parameter type hint, you immediately know this is an interface. The world

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

it's time to redesign Zend framework at all понедельник, 15 августа 2016 г., 23:02:46 UTC+3 пользователь Woody Gilk написал: > > How do you propose to resolve this common problem? > > > namespace Zend\Diactoros; > > use Psr\Http\Message\ServerRequestInterface; > > class ServerRequest implements

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

@Stefano > this comes down to personal preference Much like everything in PSR1 and PSR2 that addresses format, position of curly braces and indention. The only difference being, that there's an actually argument for why a prefixed definition would have a bad impact, while a different indentation

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

> > @Stefano > > This is a non issue... > This is important for a standard, others are adopting to what you do here > - that's the definition of a standard. Coders sees and copies what you do > and even use it as an argument when discussing the issue, it's natural for > this discussion to show up

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

​​@Rivera, I agree with you in full, and this is so fundamental that it's ridiculous that it even needs to be discussed imho.. The argument ppl are using here seems to be, "this is how we always done it"; just like many other defined PSR's, which leads to a conserved coding standard that

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

> 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

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

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

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

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

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

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

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

It is not great rationale, they might say "see, C# has a prefix convention, C# is younger language, etc.". Most of people don't want to step out of their comfort zone with suffix convention, that's it. On Monday, September 12, 2016 at 12:30:44 PM UTC+3, Dracony wrote: > > > This discussion has

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

> This discussion has been going on since the mid-90s when Java was released, at least. (Maybe longer, but that's when I first encountered it.) It's a tabs-vs-spaces class of issue. In that case shouldn't we try to look at how other languages do this? Java Core doesn't have interface

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

Sometimes suffix has influence in design decisions, because it hides some design issues which cannot be said about tabs-vs-spaces. This comparison is not correct. On Wednesday, August 24, 2016 at 4:49:42 PM UTC+3, Larry Garfield wrote: > > On 08/24/2016 07:58 AM, Art Hundiak wrote: > > I find

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

Uncle Bob's opinion: http://stackoverflow.com/a/5817904/4498485 On Wed, Aug 24, 2016 at 2:49 PM Larry Garfield wrote: > On 08/24/2016 07:58 AM, Art Hundiak wrote: > > I find it a bit amusing that exact same discussion is taking place here: > >

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

On 08/24/2016 07:58 AM, Art Hundiak wrote: I find it a bit amusing that exact same discussion is taking place here: http://programmers.stackexchange.com/questions/329098/naming-issues-should-isomething-be-renamed-to-something Different language and I prefix vs Interface suffix but the exact

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

I find it a bit amusing that exact same discussion is taking place here: http://programmers.stackexchange.com/questions/329098/naming-issues-should-isomething-be-renamed-to-something > > Different language and I prefix vs Interface suffix but the exact same arguments. -- You received this

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

+1 Many people have already very clearly stated the legitimate issues with having an "Interface suffix" standard; how you've overlooked these is mind boggling. The only objective support given so far to keep this standard, is so that some developers can know whether or not they are looking at

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

> On 21 Aug 2016, at 22:28, Matthieu Napoli wrote: > > I agree in so far that we need to acknowledge that there will be PSRs > superseding previous PSRs and there will be PSRs that are incompatible to > previous PSRs. > > Hi Lukas, could you explain what

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

> > I agree in so far that we need to acknowledge that there will be PSRs > superseding previous PSRs and there will be PSRs that are incompatible to > previous PSRs. > Hi Lukas, could you explain what incompatibilities you see? Just to be clear there is no plan to change any existing PSR.

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

> On 21 Aug 2016, at 22:07, Matthieu Napoli wrote: > > The question of consistency with existing PSRs has been raised a lot. I don't > see that as a problem. > It's OK to move forward and change a convention if we want to, each PSR is > independent from the rest.

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

The question of consistency with existing PSRs has been raised a lot. I don't see that as a problem. It's OK to move forward and change a convention if we want to, each PSR is independent from the rest. Consistency for this is a very small detail compared to developer experience, we shouldn't

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

I have to concur with those who classify this akin to "tabs vs spaces", as: - neither choice significantly hinders coding - either choice could win a vote today and lose a revote in several months I see this as one of those "pick one and be done, stick with it, and focus on harder stuff". I

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

> > That's just replacing a suffix with a prefix. Zero sum game. > @Woody, thanks for your response. I understand that you don't see the difference in describing the request as what sort of Request it is. Correct me if I misunderstood you. I will try to explain why there is a difference to me.

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

> That's just replacing a suffix with a prefix. Zero sum game. Yup, but it leaves the choice to the developer, which imho is a good thing. On Thu, Aug 18, 2016 at 5:09 PM, Daniel Plainview wrote: > HttpRequest is not good name, because Request from PSR-7 is already >

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

HttpRequest is not good name, because Request from PSR-7 is already HTTP-request. However, when I asked community about lack of different implementations, Matthew Weier O'Phinney said the following ( https://groups.google.com/forum/#!topic/php-fig/RQuMBMD48zU): > Guzzle has traditionally

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

@Woody | It depends on what type of request it is. The implementation IMO could be called `HttpRequest`. But others may have internal and external requests.. eg. InternalRequest and ExternalRequest. @Daniel Plainview | No, I'm saying the same thing as you :-) it's not good that the naming

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

> Are you saying that every PSR-7 implementation is using poor naming conventions because they define: Yes, I'm saying that. Furthermore, if you remember, I was trying to say that PSR-7 is flawed from my point of view: Request/Response should be concrete classes. There is no real place for

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

My bad, I thought your "makes it more comfortable" was in favour of keeping suffix. I mean, this should not be comfortable. ;) On Thursday, August 18, 2016 at 5:00:17 PM UTC+3, Erik Landvall wrote: > > @Daniel Plainview | thanks for your feedback, but I don't know if you > skipped the whole

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

On Thursday, August 18, 2016 at 3:31:16 AM UTC-5, Daniel Plainview wrote: > > 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:

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

@Daniel Plainview | thanks for your feedback, but I don't know if you skipped the whole message I typed after the initial sentence. What you describe is my conclusion as well. Please see my TL;DR: *- Suffixes like `Interface` adds redundant noise to the code.* *- Using the suffix makes it more

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

> I'm all in favor for noise reduction in my code, but couldn't really see any solution to the conflicting name conventions I faced Please, read messages above. > Why *specific* implementation has *non-specific* and generic name? Yet another point for removing suffix: it forces to think about

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

I had this discussion with some people from room 11. The general opinion to me seem to be *not* to use the interface suffix, so I started looking at why. I'm all in favor for noise reduction in my code, but couldn't really see any solution to the conflicting name conventions I faced. Someone

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

Hi Woody, This is not about personal preferences, this is about solving a pain point for everyone. That example is pretty much explicit: public function __invoke(ServerRequestInterface $request, ResponseInterface $response, callable $next) : ResponseInterface { } Activé 18 août 2016 à

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

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

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

> 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

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

I was asking for this since the very beginning. An Interface suffix is just as ridiculous as an Abstract prefix. If anything this convention makes the code less flexible since it makes it impossible to refactor a class to an interface while keeping the common name. Actually blogged a bit on it

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

Hi Niklas, Fair enough point. You are right that most consumers will not care or be bothered. What I had in mind is more along the lines of, if I am consuming a package and wanted to tinker or just look under the hood, the naming convention can help. Thanks, Jason On Tue, Aug 16, 2016, 6:45

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

> How do you propose to resolve this common problem? It means that Diactoros has naming issue. Why *specific* implementation has *non-specific* and generic name? Yet another point for removing suffix: it forces to think about implementation name more. Also, I suggest to read this:

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

On Tuesday, August 16, 2016 at 3:14:14 AM UTC+2, Jason Walker wrote: > > 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

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

This is a huge breaking change. Just imagine how many CI servers are going to explode due to sudden PSR2 violations when running phpcs. If I had a vote here, I'd vote -1, because: 1) Most projects can't refactor their APIs entirely due to SemVer (and wouldn't even if they could, just to adhere

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

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

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

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

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

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

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

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

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

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

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

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

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

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: -