[🚀 Feature]: [dotnet] Reevaluate Add* methods in DriverOptions

[nvborisenko]

Description

To initiate Options object we have to write:

var options = new ChromeOptions { UseWebSocketUrl = true };

options.AddArgument("remote-debugging-port=9222");

At the same time we still have an access to:

options.Arguments // ReadOnlyCollection

In general it looks like

Have you considered any alternatives or workarounds?

What if we remove all Add* methods and allow collections to be natively mutable? It will significantly simplify usage:

var options = new ChromeOptions
{
  UseWebSocketUrl = true.
  Arguments = { "remote-debugging-port=9222" }
};

And finally even to be focused on driver initialization without any intermediate local variables:

var driver = new ChromeDriver(new ChromeOptions
{
  UseWebSocketUrl = true.
  Arguments = { "remote-debugging-port=9222" }
});

[nvborisenko]

@RenderMichael @YevgeniyShunevych what do you think? Any hidden stones I missed?

It is a breaking change. If we see benefits, then we can consider it as part of major v5.

[selenium-ci]

@nvborisenko, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[RenderMichael]

I agree that this is a good idea. we can turn Arguments into an IList<string> and depreciate the AddArguments method.

However, this would likely be a pretty big change for users. Every user that sets an argument will be using this method.

I suggest we make the change for Arguments, then leave the AddArguments method as well, at least for a while.

[YevgeniyShunevych]

I generally like the idea. Just to mention that there is a plenty of such lists and methods related to them. And for consistency it would be good to change either all of the lists or none.

But there are also private dictionaries with similar Add* methods. For dictionaries, there are no read-only properties, only private fields and public Add* methods. Do you want to do something with dictionaries too, or skip? Among dictionary-related methods there is the most problematic AddAdditionalChromiumOption method, which has a tricky capability name validation.

Simple moving to public dictionary property will lose the validation, so need to think about the way to handle that. As an option, the validation can be moved to the later phase, for example to ToCapabilities method.

For lists there is also a problematic and strange Extensions property:

AddExtensions method also contains tricky file validation.

Summing up, I think it will be a good change. But it needs a careful effort. As validation (including nulls, empty strings, files, etc.) will vanish during options initialization, it should be added (and reviewed) to ToCapabilities method.

And yes, it would good, as usually, to leave old methods marked with ObsoleteAttribute for a few minor versions.