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

[Matthieu Napoli]

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

[Jeroen De Dauw]

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.

[Woody Gilk]

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 problem you put forward is:

use Psr\Http\Message\ServerRequestInterface as ServerRequest;

use Psr\Http\Message\ResponseInterface as Response;

public function __invoke(ServerRequest $request, Response, callable $next) { ... }

To wit, alias the interface in code that uses the interface if you find it annoying.

I am strongly AGAINST this change as it results in churn for an a huge number of projects without adding any value.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ea157c85-77b0-4fd4-a945-087ff1970a6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josh Di Fabio]

Thanks for putting this together Mathieu. +1

--

[Jeroen De Dauw]

Hey Woody,

You can get conflicts with existing classes and interface names in projects in both cases. There are always going to be cases where you need to use an alias (or fully qualified name). However I don't think we should avoid discussing what we think is the best naming scheme, just because one can use aliases.

As I understood the proposal here, the naming scheme change is purely for future PSRs. Hence it should not cause any churn for projects. Consider this: the current naming scheme is not creating work or problems in my projects that have a strict "no Interface suffix" policy, even though these depend on things such as PSR-3.

Cheers

--
Jeroen De Dauw | https://entropywins.wtf | https://keybase.io/jeroendedauw

Software craftsmanship advocate | Developer at Wikimedia Germany

~=[,,_,,]:3

[Niklas Keller]

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 ServerRequestInterface { ... }

If you really want to use the same name, just alias the PSR interface:

namespace Zend\Diactoros;

use Psr\Http\Message\ServerRequest as PsrServerRequest;

class ServerRequest implements PsrServerRequest { ... }

Requiring the interface to be aliased in each and every file it's used is a lot worse than having one single alias in an implementation.

[Jason Walker]

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 consumers/implementers that a type hint is dealing with an interface and not a concrete class.

Thanks,

Jason

--

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.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/7eb5ba06-515a-41c3-bae7-9db47c41b5c4%40googlegroups.com.

[Navarr Barnier]

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.

[Daniel Hunsaker]

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.

--

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.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/84a1442f-9a5a-42e8-ae8e-5b8be2fb6ce0%40googlegroups.com.

[Hari K T]

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

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/84a1442f-9a5a-42e8-ae8e-5b8be2fb6ce0%40googlegroups.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+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFjuE%2B%3D7eUG4i0jWguBUC3MYR1TbZsG-TdQsg_nacGYAd1bd1A%40mail.gmail.com.

[Stephan Hochdörfer]

What about Traits and Exceptions?

[Pedro Cordeiro]

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 to a styling standard). This will make every major project non-psr2-compliant, and will break its status as the de-facto standard.
2) If that rule must change, just get rid of it. Do NOT force projects to remove the suffix, just don't enforce the suffix anymore. That would be a minor change, as it's more permissive and therefore backwards compatible.
3) Let's be consistent and use the same rule to interfaces, abstract and traits (at least).

- Pedro.

[Matthieu Napoli]

Hi Pedro, I think there is a misunderstanding:

- accepted PSRs will not change

- PSR-2 will not change, it does not define whether or not projects should use the Interface suffix so it's not affect, this is just an internal convention for the FIG

- as a result nobody will have to change/break anything, this is only for future PSRs

About traits and the rest: I don't have an opinion about that really because the impact for consumers is much more restricted. The problem I see today is shown clearly by the middleware example (in the first email): names are ridiculously long and hard to read. This is an issue and we can solve it easily.

I'd rather solve the main problem (Interface suffix) and don't let never-ending discussions about traits and abstract classes get in the way of improving the life of thousands of PHP developers with a single simple change (that's what I fear might happen). But that's just my opinion.

--

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/Potawlu2CrQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/eaae419c-b94e-49f9-a976-be05be3ece49%40googlegroups.com.

[Woody Gilk]

On Tue, Aug 16, 2016 at 6:21 AM, Matthieu Napoli <matt...@mnapoli.fr> wrote:

names are ridiculously long and hard to read.

This is entirely subjective. You can use aliases in your own code if you find it annoying.

[Niklas Keller]

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 convention instead.

I feel the suffix gives clarity and informs consumers/implementers that a type hint is dealing with an interface and not a concrete class.

What does the added clarity whether it's an interface or class bring the consumer? The consumer shouldn't care at all. It doesn't matter to the consumer.

 

Thanks,

Jason

[Daniel Plainview]

> 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: http://verraes.net/2013/09/sensible-interfaces/

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

[Jason Walker]

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

--

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.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/9f0676f2-f411-409b-ae6b-4906daa85bd4%40googlegroups.com.

[Nicholas Ruunu]

Niklas, How would it help you exactly?

Can you describe a senario where it would be beneficial having the Interface suffix while tinkering/looking under the hood?

[Dracony]

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 too: https://phpixie.com/blog/naming-interfaces-in-php.html#

Also Java is not doing it and it worked out for them just fine

[Paul Jones]

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

[Márk Sági-Kazár]

Hi all,

Huge +1, here is why:

> When you call ResponseInterface and Response how do you understand whether it is a concrete implementation or not.

You don't, and if you do, you are doing it wrong.

Your code doesn't care whether it requires an interface to be implemented or an actual object, because it receives an INSTANCE of the type.

Classic example: do you have a car, a Ferrari or a FerrariCar?

car: object
Ferrari: type
FerrariCar: bad name

Regards,
Mark

[Stefano Torresi]

This has been discussed a great deal the first time such a decision had to be made.

If anything has changed since, is that we have more packages following the convention established by the FIG than before.

I personally follow this convention, and a lot of member projects (probably the majority, cba to check) do too and, while I understand the reasons of those who don't like it, to be honest I find such bike shedding almost close to a tabs vs spaces debate, as in: we'll never have a strong majority on either side.

In my humble opinion, once a convention is in place, the consistency argument is much harder to argue against and this fact alone is enough to dismiss the proposal.

[Daniel Plainview]

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

This argument is weak. Majority can be wrong. 

[Roman Tsjupa]

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.

There is no more reason to force the suffix than there would be a reason to force an 'Abstract' prefix or whatever.

As the Bible goes: the law was invented for the people, not the people for the law

So if there are sufficient projects that are psr compatible but dont want the suffix, why not?

Things like tabs vs spaces are important so that the code looks the same, but an interface suffix dictates much more than just text formating of your code.

--

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/Potawlu2CrQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5df31985-b3ec-4298-9627-e0beb39725a2%40googlegroups.com.

[Woody Gilk]

On Wed, Aug 17, 2016 at 4:53 PM, Roman Tsjupa <draco...@gmail.com> 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.

[Matthieu Napoli]

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

{

}

--
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/Potawlu2CrQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6KqQSZMykis%2B6676Toh7VyHL0byTTEgCPJ%2BFZioFawF7g%40mail.gmail.com.

[Daniel Plainview]

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

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/84a1442f-9a5a-42e8-ae8e-5b8be2fb6ce0%40googlegroups.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+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

[Erik Landvall]

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 pointed out to me that you would place implementations in a different namespace or sub space. But this generated some strange names such as:

```

use Foo\Bar;

use Foo\Bar\Bar as BarBar;

```

IMO, this is worse then the suffixed interface.

Lets put that into context:

```

use Foo\Cache;

use Foo\Cache\Cache as FooCache;

```

And if you like to make it even worse, what if the namespace is `Psr\Cache`:

```

use Psr\Cache\Cache;

use Psr\Cache\Cache\Cache as PsrCache;

```

...this makes no sense to me, what is what here? and why require an alias?

I understand if you don't develop modular and that then the implementations can go in a sub space, such as:

```

use Psr\Cache;

use Psr\Cache\Cache as PsrCache;

```

But sense we like components and modules that needs to be distributed as such, then better semantics IMO would be:

```

use Cache\Cache;

use Cache\RedisCache;

use Cache\MemoryCache;

use Cache\FileCache;

```

...implementations should define how they are implemented. When I later declare a dependency, I'm declaring that my class is dependent on a Cache instance, the interface suffix is redundant.

On a different note, if we are discussing to remove the `Interface` suffix, then included in the discussion should also be `Trait` suffixes and `Abstract` prefixes as mentioned before. Maybe it can be considered best discussed in different threads? In that case, please correct me, but I would say that it's the same category and the same arguments.

TL;DR

- Suffixes like `Interface` adds redundant noise to the code.

- Using the suffix makes it more comfortable to create an implementation that is not using a naming convention that declares it's implementation from a semantic perspective (eg. implementing a CacheInterface into a class named Cache)

> My impression is that the majority of member projects use the Interface suffix.

The argument that "this is the way we always have done it" is not a good argument IMO, evolving implies change. It's an interesting phenomenon though: https://www.youtube.com/watch?v=C9ySOuJ83Ww

[Michael Babker]

IMO it's as much personal preference as other aspects of coding styles.  Ultimately there is no one right answer so it's going to boil down to a majority's preference.  And at least with the projects I work with, the majority preference is to use the suffix.

[Daniel Plainview]

> 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 implementation name more.

> ...

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

In short: if your implementation name is simple "Bar" and interface is "Bar", you're doing it wrong. So you failed to describe the intention/specificity/point of your implementation.

[Erik Landvall]

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

[Woody Gilk]

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: MySqlFoo? MemcachedFoo? ZendFoo? 

Are you saying that every PSR-7 implementation is using poor naming conventions because they define:

    class Request implements RequestInterface { ... }

It sure seems like it. What should these be named? GuzzleRequest, DiactorosRequest? So then we'd have:

    namespace Zend\Diactoros;

    use Psr\Http\Request;

    class DiactorosRequest implements Request { ... }

 

This is effectively back to using the Abstract prefix, except with a vendor name. Is that really a win for anyone?

[Daniel Plainview]

My bad, I thought your "makes it more comfortable" was in favour of keeping suffix. I mean, this should not be comfortable. ;)

[Daniel Plainview]

> 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 specificity here. 

But if you really insist on it, I'd call them ZendRequest, GuzzleRequest, etc. Another way: MemoryEfficientRequest, HardCoreRfcRequest, etc. :)

> This is effectively back to using the Abstract prefix, except with a vendor name. Is that really a win for anyone?

The thing is implementation name is not significant. You program to an interfaces, not implementations.

[Ryan Thompson]

-1 PyroCMS

I believe the interface designation is important. While the instance is being passed I think it's important to explicitly designate what is expected despite behind the scenes. To refer to another members car example - an Interface is not a Car - it's a CarInterface the "class Car implements CarInterface" OR "Ferrari implements CarInterface" not FerrariCar. However "Ferrari extends Car" would work if "Car implements CarInterface".. Seems like Interface (despite what's passed in it's place for arguments) helps eliminate other otherwise different naming conventions. Doesn't matter if you pass a Car or Ferrari or FerrariCar on your end - the argument must be a CarInterface - which makes the naming convention pretty important in my book.

I also personally use purpose driven naming for other classes CarCollection, CarPresenter, CarModel so CarInterface makes the most sense in my mind. I believe it lends to cleaner more organized code.

Hopefully this makes sense ^_^

Ryan

On Monday, August 15, 2016 at 2:53:26 PM UTC-5, 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.

[Erik Landvall]

@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 convention makes it comfortable to name things with out semantics. Sorry if I explained myself poorly :)

[Woody Gilk]

On Thu, Aug 18, 2016 at 9:24 AM, Erik Landvall <erik.l...@gmail.com> wrote:

@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.

That's just replacing a suffix with a prefix. Zero sum game.

[Daniel Plainview]

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 focused on client behavior, and has optimizations around memory usage and generator driven streams; streams are its particular strength

> Diactoros and Slim focus on server side details, with the former being a full, general purpose implementation

If these implementations are truly different, I don't understand why they can't reflect it in the name (thanks to Matthew): ClientFocusedRequest, ServerSideFocusedRequest, MemoryEfficientRequest, FullRfcCompatibleRequest, etc.

If they are not truly different, why do you need the interface at all?

You either have *different* implementation or you have the only one, as simple as that.

[Roman Tsjupa]

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

--

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/Potawlu2CrQ/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/26e9735e-e9a8-4399-aa42-a56deb10298e%40googlegroups.com.

[Erik Landvall]

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. 

Lets say that you make an implementation and simply name it `Request`. Some time go by and you now need to make a new implementation in your project for the web socket protocol. Now you have an implementation named `Request` and one called, example: `WsRequest`. What makes your first implementation so generic in this case? it's just an implementation of a Request (not a request interface - the implementation part already covered that part).

Instead I would say that it makes better sense to describe your requests after what sort of request it is, eg `HttpRequest` and `WsRequest` and simply let them implement a `Request` that defines the aggregation.

[sarcasm]Or we can suffix every implementation with the `Class` keyword, and every function with the `Function` keyword, and every integer with the `Integer` keyword and every constant with the `Const` keyword...[/sarcasm]

...this sarcasm is meant to make a point how I see the suffix as redundant by associating it to a common ground.

I also noticed that this is an internal discussion, so I will stop posting here after this. I don't really understand why it's internal though?

[Chuck Burgess]

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 understand the points being made by those who don't like the suffix.  However, I see minimal benefit at best to reversing the original decision.
CRB

--

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+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ea157c85-77b0-4fd4-a945-087ff1970a6c%40googlegroups.com.

[Paul Jones]

> On Aug 18, 2016, at 18:50, Chuck Burgess <demon...@gmail.com> wrote:
>
> 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 understand the points being made by those who don't like the suffix. However, I see minimal benefit at best to reversing the original decision.

Hear, hear.

[Daniel Plainview]

I'm afraid original decision was made by inertia and without proper discussion.

As you can see from this thread, people find difficult to describe pros of the suffix, 

apart from:

* it informs consumers that they are type hinting against an interface (IDE informs as well; and from my experience there is no problem to make sure I work with an interface).

* majority uses suffix;

* it was already chosen in the past;

To be fair, last 2 of them are not arguments for the suffix, but against the change.

In other words, some people are like "yes, no suffix is probably better, but it was already done, deal with it".

We make mistakes and we should be allowed to fix them.

To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

[Lukas Kahwe Smith]

On 19 Aug 2016, at 01:50, Chuck Burgess <demon...@gmail.com> wrote:

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 see it quite similar.

Sure it can make your signatures quite long but if this hits the limits of your screen width you have other issues.

I do agree that not allowing a postfix can encourage better named classes rather than the common overly generic names.

Less generic names would also help differentiate my tabs in my IDE, having the Interface is however also a “solution” to this.

As for the argument that “Interface” might also be part of the namespace, this seems like more of the same, ie. if you currently group your interfaces into a separate namespace, then you are doing the same thing as the postfix, just in a different flavor.

So in the end it all boils down to, not important enough for me to care but important enough that consistency is appreciated.

As a result I see no point in changing.

regards,

Lukas Kahwe Smith

sm...@pooteeweet.org

[Daniel Plainview]

Consistency is a matter of time.

If PHP-FIG promoted suffix-less convention, majority of projects would change it as well.

Existing PSRs are not supposed to be relevant forever. They may be deprecated and replaced in the future.

By the way, technically, it is possible to fix it with BC with http://php.net/class_alias.

[Matthieu Napoli]

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 limit improvements for no tangible reason.

[Lukas Kahwe Smith]

> On 21 Aug 2016, at 22:07, Matthieu Napoli <matt...@mnapoli.fr> 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. Consistency for this is a very small detail compared to developer experience, we shouldn't limit improvements for no tangible reason.

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.
But overall I have not seen any significant arguments from either side that would sway me in either direction and as such I would stick with the status quo.

[Matthieu Napoli]

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. And there is no plan to replace them with new PSRs that adopt the new convention.

And if a new PSR depends on another currently existing PSR, it will use the existing names, not new (non-existing) ones. Example: PSR-15 should use `RequestInterface`, it shouldn't use `Request` just because of the new convention (because obviously it will not work: the interface does not exist under that name).

The goal is not to break anything, if you see such a scenario let's discuss it.

[Lukas Kahwe Smith]

it was a general comment in reply to your general comment that past decision should not prevent is from doing something different in the future.

[Damian Mooyman]

I would add to this that given the goal to provide a standard pattern, in the absence of legitimate issues with pre-existing standards, the status quo should prevail. The consistency and rigidity of the standard is a lot more important than what the standard actually prescribes.

[Jeff Marr]

+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 an Interface or a concrete class while coding. This is not a valid argument, because if you are using interfaces then this distinction is entirely useless to the developer.

As a developer, having to type out Interface all over the place is highly annoying and redundant. It introduces noise for no tangible benefit. Same can be said for Trait or Abstract, but Interface is more common. It also encourages poor naming habits, as developers end up using generic names for classes that would otherwise have to be an implementation-specific name, simply because the 'default' name has not yet been taken. Developers are lazy and will always try to get away with doing the minimum amount of work. And I mean that in a both a good and bad way.

I agree with all of the points that @Daniel Plainview has made so far.

[Art Hundiak]

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.

[Larry Garfield]

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.

--Larry Garfield

[Josh Di Fabio]

Uncle Bob's opinion: http://stackoverflow.com/a/5817904/4498485

--

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.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c6aaee8c-3c2f-dd0f-253f-bec5999c92a2%40garfieldtech.com.

[Daniel Plainview]

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.

[Daniel Plainview]

By the way, why PSR-8 has (had?) naming without suffix? https://github.com/php-fig/fig-standards/blob/master/proposed/psr-8-hug/psr-8-hug.md

Huggable, GroupHuggable. 

Why not HuggableInterface then?

[Dracony]

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

[Daniel Plainview]

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.

[Han Hui Teoh]

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.

[Rivera, John]

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

--
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.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/8cef0c49-0ac2-4d71-a953-28b3cd2e2992%40googlegroups.com.

[Stefano Torresi]

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?

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/FF9DE8D1-BEDD-43A4-BB16-C3B31A4890B4%40buffalo.edu.

[Daniel Plainview]

> 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.; 

[Erik Landvall]

​​@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 ultimately is self defeating for the project. Using PHP is sometimes like stepping into a time machine - and PSR's tend to work hard to maintain that position. 

..when this was voted about, you noticed that one of very few (if not the only one that voted yes) was the framework that actually addresses semantik - which this is about. One would think that a community that has not realized the important of semantik (even though the whole internet is moving in this direction) would listen to a contributor that has focused on this area.

@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 in this forum. Solve the issue by it's root, so yes it is an issue...

...anyway, enough ranting. For some reason I feel the need to criticize. I hope it can be received as constructive. I understand that this has been voted about - so there it is, a bad standard has been set. At least this discussion exist so that others that understand this as an actual issue can refer to it and contribute.

[Stefano Torresi]

@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 in this forum. Solve the issue by it's root, so yes it is an issue...

To clarify, what I meant by "non issue" is that this comes down to personal preference, and the fact that we won't be able to come to a large consensus on way or the other, makes it un-worthy of more discussion.

CS standards are doomed to be considered "bad" by at least some people, because they will never make *everyone* happy.

[Erik Landvall]

@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 and format has none, just.. that's how most ppl do it.

Erik Landvall

+34 693 74 47 77

Skype

erik.landvall

Hangout

erik.landvall

Linkedin

ErikLandvall

--
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/Potawlu2CrQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFojS1snK-%3D9rzdUxDOgtogkbsYFUEp-90XcyRJk0U0P5VJ9Hw%40mail.gmail.com.

[Dmitriy Zhirnov]

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 ServerRequestInterface { ... }

When the class name is the same as the interface name, you have to use aliases. The correct approach for the problem you put forward is:

use Psr\Http\Message\ServerRequestInterface as ServerRequest;

use Psr\Http\Message\ResponseInterface as Response;

public function __invoke(ServerRequest $request, Response, callable $next) { ... }

To wit, alias the interface in code that uses the interface if you find it annoying.

I am strongly AGAINST this change as it results in churn for an a huge number of projects without adding any value.

--
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+u...@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ea157c85-77b0-4fd4-a945-087ff1970a6c%40googlegroups.com.

[Andreas Hennings (donquixote)]

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 that I live in has a lot of legacy code where "Response" can very well be a one-off class, and no interface is to be seen anywhere.

Even worse, the class might have a lot of public methods or even some public properties (or anonymous properties) which are used by some consumer code, but which we don't want to extract into an interface.

In such a world, the suffix "Interface" offers a welcome distinction to the one-off legacy classes.

I saw this being said above by Daniel Plainview:

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.

You would still break BC for anyone who instantiates the Logger class.

[Anton Fedonjuk]

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 написал:

[Daniel Plainview]

> 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 uses Logger won't be affected at all.
Invalid instantiation in many cases may be detected at compile-time (compilation of container), and it's way safer than runtime BC breaks.

[Daniel Plainview]

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.