[🚀 Feature]: implement namespacing methods as properties

[titusfortner]

Feature and motivation

.NET copied the Java approach of using methods for namespacing:

driver.Manage().Cookies().AddCookie(cookie)

When a more idiomatic way would be to use properties. This came up when discussing adding the BiDi functionality. Rather than mixing them, or using the old way, I propose we add the properties and deprecate the methods.

Usage example

driver.Manage.Cookies.AddCookie(cookie)

[YevgeniyShunevych]

This is a good improvement. I propose also to remove, redundant from my point of view, Manage.

driver.Cookies.AddCookie(cookie)

[nvborisenko]

Let's think.

driver.Cookies.AddCookie(cookie)

Cookies looks like a state. Hmm, yes, but remote state. So driver.Cookies property looks good. Let's improve it.

driver.Cookies.Add(cookie); // instead of AddCookie

It is possible, just make Cookies as IList<Cookie>, we can mimic adding and removing cookies. Looks promising. But what about Cookie class, is it immutable or mutable. If mutable - then any modification should be reflected on server side.

We have many methods like Manage(), Cookies(), 'Navigate()'... I already proposed something like driver.AsNavigable(). The same approach could be applied for driver.AsCookable() :D (please find better naming)

[titusfortner]

We need to be careful about making large scale changes to the API. It's one thing to move from a method to a property, but rewriting everything is a lot to ask for users if we want them to keep their code up to date.

[nvborisenko]

From my point of view it is better to break once and announce this breaking change, rather than break, break, break...

[YevgeniyShunevych]

It is possible, just make Cookies as IList, we can mimic adding and removing cookies.

Unfortunately, "cookie jar" can not implement IList<Cookie> as Add and other methods should become async anyway. So it can probably be either:

await driver.Cookies.AddCookieAsync(cookie);

or:

await driver.Cookies.AddAsync(cookie);

I vote for the second one.

---

But what about Cookie class, is it immutable or mutable.

Currently it is immutable https://github.com/SeleniumHQ/selenium/blob/trunk/dotnet/src/webdriver/Cookie.cs.

---

From my point of view it is better to break once and announce this breaking change, rather than break, break, break...

Agree. This the best moment for such a refactoring if the API is breaking anyway.