feat(support): add enums support

[gturpin-dev]

This PR follows the discussion on Discord https://discord.com/channels/1236153076688359495/1323681600768315472
It add enums support using various traits to enable useful features for dealing with enums

[innocenzi]

I allowed myself to review before it's ready because I like the idea of this PR.

I love some enum helper methods, but I think they are too many. Specifically, I don't think InvokableCases is useful, and I don't feel like Comparable::is and isNot are.

[brendt]

I like the idea, and many of the methods, but I think it should be one trait: IsEnum, or IsImprovedEnum or HasEnumMethods or something alike. I don't think splitting it into separate traits adds value.

[gturpin-dev]

but I think they are too many. Specifically, I don't think InvokableCases is useful, and I don't feel like Comparable::is and isNot are.

My intend is to create a set of enums support that's firstly useful internally, but for end users, so I think we must provide some useful methods or DX even if we don't use them internally.
But this idea can be challenged, tell me :)

I like the idea, and many of the methods, but I think it should be one trait: IsEnum, or IsImprovedEnum or HasEnumMethods or something alike. I don't think splitting it into separate traits adds value.

I agree, but to support as many people as possible, I have split things in multiple traits if people don't want to import everything.
And for the most case if we want to import everything we have the Enumerates trait which import every traits, did you missed it ?

[brendt]

if people don't want to import everything.

I think it's an edge case we don't need to support :) It's better to be in line with StringHelper and ArrayHelper: one class/trait with lots of methods

[gturpin-dev]

I think it's an edge case we don't need to support :) It's better to be in line with StringHelper and ArrayHelper: one class/trait with lots of methods

I'm ok to be straightforward with this, so should we stay with the name Enumerates ? Or do you prefer things you mentionned ?
Consider that StringHelper and ArrayHelper names are currently being challenged in https://discord.com/channels/1236153076688359495/1318231202166997062

[brendt]

I'm ok to be straightforward with this, so should we stay with the name Enumerates ? Or do you prefer things you mentionned ?

Good question. Our current naming strategy for traits involves prefixing with Is or Has. But I can't really think of a good name atm…

• IsEnum
• IsImprovedEnum
• HasImprovedEnumMethods

IDK

[gturpin-dev]

Same here, so I'll start by replacing Enumerates with IsEnum for now

[brendt]

Cool! I'm still undecided on whether it makes sense to have four traits which are combined into one. I'd like the simplicity of having everything in one trait, unless there's a very good reason not to.

[brendt]

Also: tests now seem to be fine after merging main :)

[innocenzi]

I asked Claude because I'm not good at naming, and here's what he suggests:

• Accessible -> HasCaseAccessUtils (I'd use just HasAccessUtils)
• Comparable -> HasComparisonUtils
• HelperMethods -> HasEnumerationUtils
• InvokableCases (sorry 😉)
• IsEnum -> HasEnumUtils, IsExtendedEnum, HasEnumExtensions

I do prefer the word "util" over "helper", but maybe for consistency we should go with what's already used in Tempest, so "helper".

[gturpin-dev]

To be sure of what to do and what to decide @brendt @innocenzi

1. Traits combination decision:
   Should we combine separate traits into one? ( both are ok for me )

   • Pro: Keeps simplicity
   • Con: Developers can't use individual enum features

2. Naming conventions:
   The IsEnum name fits well with the rest of the codebase
   We currently have more Helpers than Utils even if I prefer Utils too
   But what if we rename ArrayHelper and StringHelper ( which is in discussion ) ?

3. Apart from this, should I remove the InvokableCases part ?

[innocenzi]

Traits combination decision

Let's let @brendt decide. imo both are fine but I understand the will to have just one trait.

The IsEnum name fits well with the rest of the codebase

It does but the name is too generic, it should be more specific

But what if we rename ArrayHelper and StringHelper (which is in discussion)?

Let's go with "helper" for consistency, if we rename that later we'll do it in bulk

Apart from this, should I remove the InvokableCases part?

I personally definitely think so!

[brendt]

Traits combination decision

Let's have one trait for now 👍

It does but the name is too generic, it should be more specific

IsEnumHelper? If possible, I would really like to keep our naming convention of Is or Has for traits. I think Helper makes sense, since we have it in other places as well. We could debate whether Helper should be renamed, but I think that's outside the scope of this PR. I'd say, let's go with IsEnumHelper, and have another debate after this PR on what we want our helpers to be named

Apart from this, should I remove the InvokableCases part?

Yes, let's remove

[brendt]

Ping me when ready btw :)

[gturpin-dev]

@brendt then it's ready for me👌
Does @innocenzi wants to review something else ?

[innocenzi]

LGTM 👍

[brendt]

Thanks for all the effort you put into this @gturpin-dev ! Let's merge :)

Would you be able to also send a PR to the docs about it? It could go on https://tempestphp.com/docs/framework/primitive-helpers/

/

[gturpin-dev]

@brendt Sure, I'll check to make input there 🎉

Thanks for pointing out the locations 👌

[brendt]

I've added a docs entry for this :)