What's the deal with StringEnum??

[SlyckLizzie]

Why do the tests for response objects require enumerations to be wrapped in a StringEnum? It's tacky and not needed in my opinion. Why is it there and why can't we remove the checks?

[SlyckLizzie]

This is what a response object looks like when using the StringEnum. Not happy with this. Can I override?

[khellang]

You obviously didn't read (or underatand) the documentation 😆 I suggest you go back and read the documentation before embarrassing yourself like this. It solves a very real problem, which is just as relevant today as it ever was, and it shouldn't be removed. If you don't want it in your JSON, maybe avoid serializing it, either by using your own DTOs or using a converter.

[SlyckLizzie]

Way to be rude...

[khellang]

Saying something is

tacky and not needed

and

outdated and unnecessary

Without even knowing why it's there in the first place is also kinda rude. Especially after being pointed to the documentation which explains in detail how it works and why it's there.

I would like to discuss this and challange the need to force the practice.

I, for one, would love to hear your alternative proposal. Just make sure you understand the problem(s) which StringEnum<T> solves to avoid wasting everyone's time 😅

[SlyckLizzie]

I said that BEFORE you linked to the documentation. Perhaps you were the one that wrote that StringEnum to be so defensive about it? And I will send an alternative proposal. Thank you.

[khellang]

I said that BEFORE you linked to the documentation.

The first part, yes. The second, no. Both are rude either way.

Perhaps you were the one that wrote that StringEnum to be so defensive about it?

As a matter of fact, yes, it was my proposal and I wrote the initial code, but I'm not at all being defensive about it. I'm being defensive about the way you denigrate free open source solutions to problems you haven't even understood (or blatantly ignored). Stepping up to an open source project and saying "why don't you just use enums?" without appreciating any history (enums was used directly before StringEnum) or context (enums are problematic for open sets) just isn't helpful. The type does exactly what it set out to solve, but if anyone comes along with a better solution, I'm all for it. Looking forward to your proposal 😄👍