Feature Request: Const Value Generations to get around "A constant value is expected"

[JoshuaNitschke]

Describe the feature

Hi Steve,

I am really digging Vogen and I thought I'd give this library a try. One thing I have found while switching enums over is that not being able to use the "enumerations" in switch statements is a bit annoying for example, where response is an Intellenum (of type string), I have to do something like this:

State = response.Value switch
{
    "yes" => Request.Accepted,
    "no" => Request.Declined,
}

What if the library also generated the Values as constants? What do you think of this idea? This would also help for XUNIT theory InlineData.

State = response.Value switch
{
    Response.YesValue => Request.Accepted,
    Response.NoValue => Request.Declined,
}

I'm currently adding these by hand where I have a lot of switches.

Alternatively, similar to Dunet a Match / Switch function could be implemented?

[JoshuaNitschke]

@SteveDunn I see a few thumbs up on my request, would you take a PR adding this, or are you morally opposed?

[SteveDunn]

Thanks for the feedback @JoshuaNitschke , and apologies for the delay in getting back to you (hectic few months!). I'm very glad you find it useful.

That sounds like a great idea! Any help would be appreciated in implementing it. I absolutely love Dunet and I hope to see it used more widely in the future.

Thanks once again (and apologies once again!)

[JoshuaNitschke]

Thanks Steve, no need to apologize. I'll try to find some time to work on this this month. I appreciate all the work you have put into Vogen and this library. :)

[NoahStolk]

This would be a great feature. 🎉 Out of curiosity, did you ever find the time to start working on this @JoshuaNitschke? If not, I would be happy to try and implement this feature, or otherwise contribute in any way I can.

[JoshuaNitschke]

@NoahStolk unfortunately, I have not yet had time to start working on it yet. Do let me know if you start!

[NoahStolk]

Hi @JoshuaNitschke, I've started to work on this and have opened a draft PR: #131

Currently, the source generator appends Const Value to the const field names to prevent naming collisions. If anyone has a better idea, please let me know. Any other feedback would be appreciated too.

I might also need to add some more tests (although the current tests are pretty sufficient already I think).

[JoshuaNitschke]

In my hand written code I was using Value as the suffix, which I prefer personally but nothing I'd get hung up on.

I really appreciate you taking a stab at it!

[NoahStolk]

Yeah I've already changed it. Shortly after I submitted the PR I read the original proposal again and realized Value would be a better suffix (since it matches the Value property). 😄

[NoahStolk]

Hi @SteveDunn, are you planning to create a new beta release any time soon? Or is there still a lot of work that needs to be done first? I really appreciate this library and would love to try this out and clean up some code. 😄 (No rush of course, I understand if you are busy!)

[SteveDunn]

Thank you for the kind words. I am working on it in the background. I think a new beta release should be done. I'll hopefully get around to it this week. It might not be perfect though, but hopefully good enough (as it doesn't actually do much)

[NoahStolk]

Thank you very much for the release! Just updated and everything works as expected! 👍

[SteveDunn]

Great to hear @NoahStolk !

[JoshuaNitschke]

@SteveDunn @NoahStolk I upgraded as well and was able to clean up a bunch of temp code. All tests passing. Thanks!

[NoahStolk]

It seems that const fields are no longer being generated in version 1.0.2. Looking over the changes in MemberBuilding/MemberGeneration.cs real quick I've noticed that the following line has been changed:

- if (!item.IsConstant || item.MemberProperties.Count == 0)
+ if (!item.IsConstant || item.MemberProperties.ValidMembers.Any())

Shouldn't this be !item.MemberProperties.ValidMembers.Any()? (Note the ! at the start.)

I've not extensively looked into this yet (don't have the code on my computer right now), so apologies if I am mistaken. (And apologies for not including a unit test in my original PR!)

[JoshuaNitschke]

Confirming that the new package release has broken my unit tests as well that rely on this feature.

[SteveDunn]

Oops - apologies for that and thanks for pinpointing the cause of issue! A new build is happening right now.

[NoahStolk]

All builds succeeding and tests passing with 1.0.3. 🎉 Thanks for the quick fix!

[SteveDunn]

All builds succeeding and tests passing with 1.0.3. 🎉 Thanks for the quick fix!

Excellent - thank you!