Consider using generics for better IDE support

[spatie]

Consider using generics for better IDE support

[Gummibeer]

I also prefer TEnumValue in this case.

[Gummibeer]

Hey,
At first: I'm not against this!

But even if value is an integer the construct still accepts integer and string. As it's instantiatable by the value and methodname.

Which is also always required for StatusEnum::DRAFT().

So it would be more correct to adjust the type of read-only property $value. 🤔

[AAllport]

Hi Gummibeer,

I see what you're saying (in regards to the instantiation). Although not quite following with that last line.

But in regards to how it will affect the DX,

If the following were replaced with templates:

• https://github.com/spatie/enum/blob/master/src/Enum.php#L38
• https://github.com/spatie/enum/blob/master/src/Enum.php#L52
• https://github.com/spatie/enum/blob/master/src/Enum.php#L256

Then when calling StatusEnum::DRAFT()->value you can remove the ambiguity that it may be an int or a string.
This enforcement (albeit only caught by the IDE and static analysis) can greatly help in a type-safe environment, where a downstream, maybe relying on it being backed by ints.

Could also prevent issues where you're storing ints in your database, and a newcomer comes to the team and attempts to add a string to the value set.
Granted, these issues should also be fixed in tests & code reviews. just feels any opportunity to catch this sort of issue would be awesome!

[Gummibeer]

I'm not really into templates - but so far I got this would allow a user to override @template EnumValue with int only instead of the packages default int|string and this would adjust everywhere in the corresponding class!?

I totally like type-safety and if I got it right: go ahead!
If I haven't got it: please correct me. 🙈

For the __construct() we could use EnumValue|string? 🤔 This would make it clear that we allow whatever your value is and the string on top.

[AAllport]

I'm not really into templates - but so far I got this would allow a user to override @template EnumValue

That's correct, I believe it's often described as PHP's answer to Generics!
I'm also I planning on contributing to Laravel to get an uptake in this: laravel/framework#34110

Hadn't considered using EnumValue|string for the constructor, but this is a great idea!

PR Inbound!

[Gummibeer]

One thing, if it's possible I would prefer a namespaced template to prevent conflicts.
If not can we go with SpatieEnumValue?

[AAllport]

Worth noting: https://psalm.dev/docs/annotating_code/templated_annotations/

The names of your templated types (e.g. TKey, TValue don't matter outside the scope of the class or function in which they're declared.

(So, I was originally gonna be lazy and use T) I believe it's the same behaviour with PHPStan

Happy to use SpatieEnumValue, but may be better to use either TEnumValue, TSpatieEnumValue to maintain the convention of using T to dictate it's a template?
I have no preference as such, but personally think TEnumValue looks better!

Thoughts?

[AAllport]

Also, (following some reading) looks like it'll need a slight update to spatie/laravel-enum for the inheritance (happy to sort myself also)!

See:

• https://psalm.dev/r/1ede5efb5d
• https://psalm.dev/docs/annotating_code/templated_annotations/#template-inheritance