Allow anonymous objects to implement IDictionary<string,object> about roslyn

[HaloFour]

Ya know I was tempted to add a comment to the feature request for params IEnumerable<T> to also ask for something like params IDictionary<string, T> where the latter would be satisfied by using named arguments:

void Execute(string command, params IDictionary<string, object> arguments) {
   // do stuff here
}

Execute("SELECT * FROM table WHERE name = @name AND date = @date;",
    name: "Joe",
    date: DateTime.Today
);
// equivalent to
Execute("SELECT * FROM table WHERE name = @name AND date = @date;",
    new Dictionary<string, object>() {
        { "name", "Joe" },
        { "date", DateTime.Today }
    }
);

What do you think?

[mburbea]

That's pretty great. Very similar to python's **kwargs and would solve most of my needs and be a nice boon to APIs that need this type of functionality. However, like the previous discussion if the usage is primarily for iterating and with a small number of arguments it might be worthwhile to create something more specialized. Dictionaries are pretty lightweight but certainly an object with an array of KeyValuePairs would be cheaper.

[HaloFour]

Absolutely. The compiler could emit a specialized struct which implements the interface (as large and as obnoxious as that is).

For your use case (an SQL statement) I imagine that we'll see more of a push towards string interpolation via FormattedString, although that lacks the capacity to get the names of the holes at the moment which is a limiting factor.

[mburbea]

If I wore my DBA hat, I'd groan at the idea of replacing an rpc to sp_executeSql to a FormattedString that is potentially susceptible to sql injection. I think formattedString is really cool and will help in general, but I see this still as a useful construct for sql.

[HaloFour]

If the API accepted FormattedString it could apply its own interpolation strategy so that the string contained generated parameter names rather than embed the values, something akin to:

public static int Execute(this SqlConnection connection, FormattedString command) {
    using (SqlCommand command = connection.CreateCommand()) {
        int length = command.Args.Length;
        string[] parameterNames = new string[length];
        for (int i = 0; i < length; i++) {
            string parameterName = "@p" + i;
            parameterNames[i] = parameterName;
            command.Parameters.AddWithValue(parameterName, command.Args[i]);
        }
        command.CommandText = String.Format(command.FormatString, parameterName);
        return command.ExecuteNonQuery();
    }
}

Which you should be able to call like this:

string name = "Joe";
DateTime date = DateTime.Today;
int result = connection.Execute($"SELECT * FROM dbo.table WHERE user = {user} AND name = {name};");

Which would execute the following SQL:

SELECT * FROM dbo.table WHERE user = @p0 AND name = @p1;
-- @p0 NVARCHAR(4000) N'Joe'
-- @p1 DATETIME2 '2015-01-21 ...'

Of course if FormattedString also carried the hole names then you could name the parameters better.

[mburbea]

I retract my comment FormattedString actually does look really good for that goal. There are other cases where I won't be passing a string parameter and it would be useful to be able to use keyword arguments.

[gafter]

We have no expectation of ever doing anything like this.

[alex-jitbit]

What I ended up doing is create a dummy class like this:

public class Params : Dictionary<string, object> { } //syntax sugar

And then use it like this with Dapper to prevent (slow) reflection:

connection.ExecuteReader("SELECT * FROM Table WHERE ID=@ID", new Params { ["ID"] = 123 };