Using implicit operator overloads to keep your C# API discoverable and open

Re:Using implicit operator overloads to keep your C# API dis... by pradocchia on Friday May 09, 2014 @01:14PM (#7721996)

It still provides some of the same ergonomics. You can put away the mental cheat-sheet ("1: gold, 2: silver...."). Your IDE can find all uses of BookTypeId.Gold(), rather than textual occurrences of "1". Etc.

The static quality of enums is only one of their features, and sometimes a hindrance, and it good to have other options.

[ Parent | on HN ]

Re:Using implicit operator overloads to keep your C# API dis... by andrea_s on Friday May 09, 2014 @01:21PM (#7722046)

sure, but I can't see how this is supposed to increase discoverability of the API...

I see "here is something that looks like an enum, and its possible values are gold, silver and bronze. But you can also give 10, 42 or any number as a value and it will still work".

I don't mean to be overly critical (clearly this approach has worked well for the author), but I am a bit unsure about the perceived benefits.

[ Parent | on HN ]

Re:Using implicit operator overloads to keep your C# API dis... by pradocchia on Friday May 09, 2014 @02:01PM (#7722333)

Yeah, I'm not sure how much it increase discoverability, plus users pay the cognitive cost of quirky patterns.

I might have used an enum plus a second constructor to wrap the explicit conversation. I guess it depends on what's going on in the rest of the API.

[ Parent | on HN ]