[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 }

};
var document = new BsonDocument(dictionary);

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:

  • we should have both IDictionary and IDictionary<string, object> overloads
  • that causes an ambiguity when passing a Dictionary<string, object> value because it matches both
  • the ambiguity can be resolved by adding an overload specifically for Dictionary<string, object>

I have found a few other classes that implement both IDictionary and IDictionary<TKey, TValue>:

ConcurrentDictionary
SortedDictionary
SortedList

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.

Generated at Wed Feb 07 21:36:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.