1

I'm building a HTTP-API wrapper for .NET, which has a bunch of methods to set data in an object, and then it serializes the data and sends it to my server. There are 6 datatypes allowed:

  • string
  • int
  • long
  • float
  • double
  • DateTime

My data attributes use generics:

SetAttribute<T>(string key, T value)

So there is only one generic method to set data. Since I cannot constrain the data types to the 6 mentioned, I use run-time checks and throw an exception when the wrong data type is used.

Now for my problem: I have two versions of SetAttribute, one that takes a single value (of type T) and one that takes multiple values (of type IEnumerable<T>). The problem is that when a programmer uses this wrapper and does not specify the type parameter, the runtime guesses which method to use, for instance:

SetAttribute("testkey","thing,anotherthing,athirdthing".Split(','))

This defaults to the single value method and T is String[] which of course makes my method cast an exception because String[] is not a valid type. If you specify:

SetAttribute<string>("testkey","thing,anotherThing,aThirdThing".Split(','))

The runtime chooses the correct method (multi-value) and no exception is cast because T is then string.

My question: how can I label my methods so that the type parameter is mandatory and must be explicitly defined? Or do I have to detect this at runtime and redirect to the multi-method myself?

DukeOf1Cat
  • 1,087
  • 15
  • 34
  • *This defaults to the single value method and T is String[] which of course makes my method cast an exception because String[] is not a valid type* don't understand this? – cuongle Sep 25 '12 at 10:34
  • When you use SetAttribute("testkey","thing,anotherThing,aThirdThing".Split(',')) how do you assign the string[] returned by string.Split to a string? – Ignacio Soler Garcia Sep 25 '12 at 10:35
  • 2
    I would say using a public generic SetAttribute in this case isn't necessarily a good idea. Since the types are so constrained, you should probably just write the overloads and move the errors from runtime to compile time. It would also allow you to take `IEnumerable` etc. with another 6 overloads and eliminate the problem you're having entirely. You can always _implement_ SetAttribute with a private generic and just call that from each overload, that will remove some duplication. – Joachim Isaksson Sep 25 '12 at 10:41
  • @CuongLe Le since the type parameter is not mandatory, the runtime (or compiler?) guesses which method to use. In this case it guesses wrong. – DukeOf1Cat Sep 25 '12 at 10:47
  • @SoMoS string[] is an IEnumerable so it should use the multi-version of the method. But it doesn't. – DukeOf1Cat Sep 25 '12 at 10:48
  • See also this question: http://stackoverflow.com/questions/10354982/c-sharp-overload-resolution-rules – Tim Rogers Sep 25 '12 at 10:49
  • @JoachimIsaksson this is an alternative but it seems as a hassle to have to use 12 different methods when 2 public generic methods are just much prettier. Are you saying that there is no way to enforce the type parameter? – DukeOf1Cat Sep 25 '12 at 10:50
  • @JoelWKall Afaik no, not if you want compile time checking. In this case your generic (since it's unconstrained) is pretty much the same as taking `object value` as a parameter. It works, but moves all checking to runtime (and in that case you can just `if(value is IEnumerable)` to solve your problem) – Joachim Isaksson Sep 25 '12 at 10:54
  • @JoachimIsaksson So basically there is no smooth way of doing this? I have to pick the lesser of several evils? In that case I think several overloaded non-generic methods is best, then I can do without the run-time checks. – DukeOf1Cat Sep 25 '12 at 10:56
  • @JoelWKall Moved the comment to an answer below to avoid having lengthy discussions here. – Joachim Isaksson Sep 25 '12 at 11:07

4 Answers4

2

Given a parameter type, the compiler finds a best match from your overloads. If you cast your string[] to an IEnumerable<string> you will probably find it works as expected because the best match is a method that has exactly those parameters. But you have no method that takes a string[], so given one as a parameter, the compiler makes the best guess it can.

I would have two separately named methods rather than overloads otherwise it is too easy to run into this problem. Or have 6 separate overloads, as @Joachim suggests.

Tim Rogers
  • 21,297
  • 6
  • 52
  • 68
  • Where is T in the comparison tree? Is it the same as object? Or is it always true for any type? Because IEnumerable should be closer to String[] than object is, right? – DukeOf1Cat Sep 25 '12 at 11:01
  • 1
    Read [Jon Skeet's excellent blog post](http://msmvps.com/blogs/jon_skeet/archive/2010/10/28/overloading-and-generic-constraints.aspx) on this subject. The point is that overload resolution occurs *after* generic type resolution. Therefore, you are resolving between one method that takes a `string[]` and one that takes an `IEnumerable`. The first obviously wins. – Tim Rogers Sep 25 '12 at 11:07
2

Ok, this was originally a comment above since it doesn't necessarily answer your original question but suggests an alternate approach;

I would say using a public generic SetAttribute in this case isn't necessarily a good idea.

Since the types are so constrained, you should probably just write the overloads and move the errors from runtime to compile time. It would also allow you to take IEnumerable<string> etc. with another 6 overloads and eliminate the problem you're having entirely.

You can always implement SetAttribute with a private generic and just call that from each overload, that will remove some duplication.

It will also more or less eliminate the need for runtime checks, since the types are already constrained by the compiler.

Joachim Isaksson
  • 176,943
  • 25
  • 281
  • 294
  • I should be able to manage with 4 overloads right, since int and long can use the same method (taking long) and the same for float and double? – DukeOf1Cat Sep 25 '12 at 11:33
  • 1
    @JoelWKall If you're not interested in the difference between the two types (for example float vs. double) inside the method, you can use the compiler to "promote" as you say and save some overloads. If you need to know what type was actually passed in of the two, you need to create the extra overload since you'll otherwise never know inside the method whether it was passed a float or a double. – Joachim Isaksson Sep 25 '12 at 11:37
0

One solution would be to break your original method into 6 non-generic overloads, and add another generic overload for collections:

void SetAttribute(string key, int value);
void SetAttribute(string key, string value);
// etc

// abd this takes care of collections:
void SetAttribute<T>(string key, IEnumerable<T> value);
Jon
  • 428,835
  • 81
  • 738
  • 806
0

I would suggest a better solution would be to test whether the value passed in is IEnumerable after it fails everything else and treat it as such if it is. (I imagine that you're handling IEnumerable as a seventh case already).

CrazyCasta
  • 26,917
  • 4
  • 45
  • 72
  • Basically add a test in my single-method and see if it is an IEnumerable, and if so, redirect to my multi-method? I could do that but it involves more runtime checks which, to be honest, is not always the best chioce. If I could, I would remove them altogether. Perhaps @JoachimIsakssons solution is the best after all... – DukeOf1Cat Sep 25 '12 at 10:54