[CSHARP-290] Ambiguity between overloads with an IDictionary or an IDictionary<string, object> parameter Created: 27/Jul/11 Updated: 02/Apr/15 Resolved: 04/Aug/11 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | None |
| Affects Version/s: | 1.1 |
| Fix Version/s: | 1.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Robert Stam | Assignee: | Robert Stam |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Description |
|
When we introduced new overloads of BsonDocument constructors and methods with a non-generic IDictionary parameter (which we did to be Powershell friendly) we created an ambiguity with other overloads with a generic IDictionary<string, object> parameter. Here's one example that won't compile anymore: var dictionary = new Dictionary<string, object> { { "x", 1 } }; There are others that need to be found and fixed as well. |
| Comments |
| Comment by Robert Stam [ 04/Aug/11 ] |
|
Implemented the changes proposed in the previous comment. |
| Comment by Robert Stam [ 04/Aug/11 ] |
|
Current thinking:
I have found a few other classes that implement both IDictionary and IDictionary<TKey, TValue>: ConcurrentDictionary but I don't think they are used frequently enough to merit adding overloads for all of them. If someone needs to pass one of these less frequently used classes as an argument they will have to put in a cast to resolve the ambiguity. |
| Comment by Robert Stam [ 01/Aug/11 ] |
|
Good point. Supporting generic and non-generic interfaces at the same time is turning out to be harder than expected! Will reopen this issue. |
| Comment by Aristarkh Zagorodnikov [ 01/Aug/11 ] |
|
Unfortunately, this change breaks existing code, because IDictionary<string, object> does not implement IDictionary interface, so if you're passing the IDictionary<string, object> instead of a Dictionary<string, object>, it fails since there's an ambiguity. |
| Comment by Robert Stam [ 28/Jul/11 ] |
|
Removed overloads with IDictionary<string, object> parameter. The remaining overload with non-generic IDictionary argument can take generic IDictionary<string, object> argument values and will do the the right thing with them. This solves the ambiguity caused by having two similar overloads. NOTE: this is a breaking change at the binary level because we have removed an overload. But at the source code level it shouldn't break any client code, which must merely be recompiled to work with this change. |