Named parameter version of the API

[OlsonDev]

This is just a generic request. I've noticed this client/API is very Boolean happy. I'd much rather see overloads which take in specific purpose enums.

I just put together a demo app and in reviewing the code I wrote yesterday, I'm having difficulty reading it. Compare what I have with what it could be.

What I have:
model.QueueDeclare(queueName, true, false, false, null);

What I could have:
model.QueueDeclare(queue:queueName, durable:true, exclusive:false, autoDelete:false, arguments:null);

What I'd like to have:
model.QueueDeclare(queueName, Durability.Durable, Scope.Public, OnEmpty.DoNotDelete);

The names of the enums are merely a suggestion -- if you can think of better names, go for it. I'd just like to see more overloads, default parameters, & enums.

Regarding default parameters, I'd even go so far as to say model.QueueDeclare(queueName) is acceptable so long as IntelliSense told me what all the defaults were.

[michaelklishin]

Hi @OlsonDev.

I agree it would be nice to have a named arguments alternative but having OnEmpty.DoNotDelete when there is already a concept of auto-deleted queues seems excessive to me. In fact, Onempty.DoNotDelete is not correct,
while Scope.Public is not very descriptive. Both "auto-delete" and "exclusive" are boolean values in the
protocol.

Other clients have introduced their own terminology in the past and it always ends up confusing users. I'll file an issue
in the internal RabbitMQ bug tracker for the named argument alternative.

[michaelklishin]

Internal bug number is 25891.

Using named arguments will mean moving the minimum required .NET version to 4.0. We currently support .NET 3.0
(up from 1.1 earlier this year). It may take some time before 4.0 can be considered as a baseline.

[OlsonDev]

Thanks for looking at my issue.

While the enums may seem excessive, the current API seems to map the standard(s) 1-for-1 (not that I'm familiar with the standard)... which isn't bad but some abstraction could help a lot with readability -- especially with the sheer number of Booleans being passed around in this library.

Just Google around for Boolean vs. enum. You'll see a lot of results similar to this where the general consensus seems to be "prefer enums, let the compiler/JITer do the dirty work of converting to Boolean).

OnEmpty.DoNotDelete and Scope.Public were just examples -- call them what you will, whatever's most readable. I'd just prefer enums over someMethod(true, false, true, true, false). It's Microsoft's guideline... granted this was written in 2004 but a lot of it still holds true, in my opinion.

[michaelklishin]

So, with .NET 4 (required in master), it is already possible to do something like

ch.QueueDeclare("", durable: false, exclusive: false, autoDelete: true, arguments: null)

This trades significant readability improvements for a tiny latency increase (for the I/O bound methods in our client). Looks like the only thing we should do is to update our tutorials to use named arguments and .NET guide to mention both ways of invoking methods.

Needless to say, I wish javac had this feature :)

[michaelklishin]

Will file a separate issue for the tutorials.