Naming convention for enumerations

[0x6d6c]

Moved from symfony/symfony#45516.

---

Description

According to coding standards, PHP classes of type Interface and Trait should have a suffix: Trait and Interface respectively:

• Suffix interfaces with Interface;
• Suffix traits with Trait;

PHP 8.1 introduced enumerations that are also some kind of a PHP class so I think that for consistency reasons Enum suffixes should be added as a new naming convention:

Example

• Suffix enumerations with Enum.

[derrabus]

Thank you for bringing this topic up, @mi6th! Here's my proposal: #16537

[0x6d6c]

I read your proposal, @derrabus. To me it's logically when we do suffix enums with Enum because it's consistent with another PHP class types: interfaces (*Interface), traits (*Trait). The docs also recommend to prefix abstract classes with Abstract (except PHPUnit *TestCase).

So:

• interface class keyword becomes an Interface suffix
• trait class keyword becomes a Trait suffix

and

• abstract class keyword becomes an Abstract prefix

That's wy I proposed that enum class keyword should be considered to be included in the class name as a suffix.

[derrabus]

I understand that and I disagree with that proposal.

If we want to enforce such a suffix, we need to ask ourselves what problem we want to solve. And unless you come up with a good one, I'm not convinced that we should enforce a suffix.

The current rules do serve a purpose when it comes to contracts and default implementations. Since classes, interfaces and traits occupy the same name space in PHP, you cannot have a class and an interface with the same name. So if you define a contract (either as interface or abstract class) and a default implementation (either as class or a trait or even both), you have a naming problem.

A good example is the event dispatcher. If the interface were named EventDispatcher already, how would you name the default implementation which in 98% of the cases is the one implementation that you want? You would probably end up with a DefaultEventDispatcher or a EventDispatcherImpl or you name it. We would probably even have a naming rule for similar implementation classes then. You will find names like that in codebases that explicitly discourage the Interface suffix.

Another example is the HTTP Client: The HttpClientInterface provides you with a contract for logic that interfaces with an HTTP client while the HttpClientTrait provides common functionality that you will need when writing an implementation of that interface. Both, the trait as well as the interface, could reasonably be named HttpClient. Again, the suffixes resolve a naming collision here.

For enumerations however (which under the hood are just a special kind of class), I don't anticipate this kind of problem. And that is why I don't see a dedicated Enum suffix as the right thing to do.

[0x6d6c]

I must admit that your explanation convinced me. I didin't think about it in that way – I focused more on the, let's say syntax and not the possible implementation. And the dedicated namespace for enums should solve problem.

Thank you for your time & explanation!