Humanizr / Humanizer

Humanizer meets all your .NET needs for manipulating and displaying strings, enums, dates, times, timespans, numbers and quantities
Other
8.52k stars 947 forks source link

FR: alternative EnumCache and extensions to De/Humanize enums #1490

Open KillyMXI opened 3 months ago

KillyMXI commented 3 months ago

My understanding is that there is currently DehumanizeTo extension that is intended to work exactly in reverse of Humanize. At the same time, it is not necessarily what I expect as a user of the library.

public enum ExampleEnum
{
    [Display(Name = "The foo", Description = "something about what effect Foo makes")]
    Foo,
    [Display(Name = "The bar", Description = "something about what effect Bar makes")]
    Bar,
}

I don't expect to parse input string in the format of description. I expect the input script to be the best approximation of a parseable name.

And so, I think the reasonable string-to-value dictionary may consist of normalized strings taken from ToString value, display name, description, whatever else can be located in the attributes...

Current implementation prioritizes Description and takes only one string:

https://github.com/Humanizr/Humanizer/blob/3d80235a9acf3b32acae65bf2b2d9284c54a20de/src/Humanizer/EnumCache.cs#L64-L73

I don't understand the utility of this. It breaks valid usage scenarios. And it seems that for a workaround I have to reimplement a custom dehumanizer from scratch.

This is probably related to #700.

By extension, if I need the Humanize function - I will face the same issue - I don't necessarily need the description - I may prefer to:

To resolve both problems, alternative implementation to current EnumCache and extensions might be conceived, probably in parallel to the existing one to avoid breaking change. It may be not exactly what I expect it to be to solve each direction issue, but I'd like this to be a started for a discussion at least.

Seems like Humanizer might've been around before System.ComponentModel.DataAnnotations.DisplayAttribute and is still based on more limited assumptions.

From DisplayAttribute.cs:

Property Intended purpose
Name The name is generally used as the field label for a UI element bound to the member bearing this attribute.
ShortName The short name is generally used as the grid column label for a UI element bound to the member bearing this attribute.
Description Description is generally used as a tool tip or description a UI element bound to the member bearing this attribute.
Prompt A prompt is generally used as a prompt or watermark for a UI element bound to the member bearing this attribute.
GroupName A group name is used for grouping fields into the UI.

Of those, I only really see Name and ShortName as well suitable for de/humanization.