Enum v Class Constants & PSR-4

[maccieD]

I'm doing the conversion of my codebase from PHP 7.2 to 8.2 and trying to take advantage of any new features i can.

I like the idea of using enums as I've always disliked having to load/parse a whole class just to access (for example) only 1 constant.

However, I'm struggling with the structure of the enum files.

I currently have a simple class Contact which has constants for the state ACTIONED and UNACTIONED.

When someone makes a contact I have constants in the same class for the contact type TYPE_QUERY, TYPE_SUGGESTION, TYPE_COMPLIMENT etc.

In this simple example, an enum equivalent would be:

    ContactState (Actioned/Unactioned)

and an enum class for

    ContactType (Query,Suggestion, Compliment).

Would this be right? It's just seems a little overkill having 2 files and 1 of them having just 2 values in it?

 

[Barand]

You could put them all in a single ini file EG

contacts.ini

;;
;; constants definitions
;;

[contactstate]
0 = Unactioned
1 = Actioned

[contacttype]
1 = Query
2 = Suggestion
3 = Compliment

code

$constants = parse_ini_file('constants.ini', 1);

echo $constants['contactstate'][1];   // Actioned
echo $constants['contacttype'][3];    // Compliment

You can use that ini file to create dropdown menu options too. Something that is a PITA with enum values/meanings.

If you are using a database, put each of those ini sections in separate tables instead of the ini file method.

[maccieD]

Doesn't that defeat the point?

We're back to using literals for indicies, you have to know that [3] is a compliment.

Also, you now have the overhead of reading an "external" file? Yes I know that the enum is a class that has to be loaded, but surely there's a chance in its in the opcache unlike the ini file?

[kicken]

58 minutes ago, maccieD said:

but surely there's a chance in its in the opcache

Yes, which is why I wouldn't worry about the whole having to load a class thing.  Chances are it'll be cached, either in the opcache or filesystem cache so it's not a big deal.

If your enums are related to just one class, then you could just define them in the same file as that class, but then you end up with potential auto-loading issues if you later decide you want to use the enum without using the associated class.

In the past, whenever I have enum like constants, I have generally always defined them in their own class (and thus file) anyway, so transitioning to a proper enum isn't much of a change.

Regarding enum vs constant, I will use a constant when it's use is generally limited to just that class, either strictly internally (in which it's a private constant) or only as a parameter to methods on that class.  I'll use an enum if the usage might extend across various classes or be used outside of a class (ie, a method returns one of the enum values).

 

[maccieD]

16 hours ago, kicken said:

Regarding enum vs constant, I will use a constant when it's use is generally limited to just that class, either strictly internally (in which it's a private constant) or only as a parameter to methods on that class.  I'll use an enum if the usage might extend across various classes or be used outside of a class (ie, a method returns one of the enum values).

This is exactly what I'm struggling with, I resorted to the "text-book" answer in that everything should be enums and ideally non-backed. But I guess I am overthinking it in terms of performance. 

I even set up 2 tests, one that simply echoed a class constant and one that echoed a enum class value:

Class constant (simple class with 8 constants, 4 properties, 11 methods, 174 lines of code): average load/execution time (over 5 runs) - 0.5162 ms.

Enum class value (enum with 5 backed cases): average load/execution time (over 5 runs): 0.2928ms

Were talking about half and 0.2 millisecond here!