[GODRIVER-964] make option type construction consistent with the options package (e.g. readpref, readconcern, writeconcern) Created: 15/Apr/19 Updated: 19/Dec/22 Resolved: 19/Dec/22 |
|
| Status: | Closed |
| Project: | Go Driver |
| Component/s: | Options & Configuration |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Sam Kleinman (Inactive) | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Description |
|
Revised: The mongo/options package uses chained-setters for constructing options. But types referenced by mongo/options, such as WriteConcern, ReadConcern, etc., are constructed with functional options style. Mixing styles confuses users and could be revised/replaced for consistency. Additionally, some types are defined within mongo/options (such as Credential, Collation, etc.) but others have their own package (e.g. readpref.ReadPref, etc.). There is no obvious guide for what to expect to find where. Original:
|
| Comments |
| Comment by Matt Dale [ 12/Dec/22 ] |
|
I've created tickets that describe proposed simplifications to the writeconcern, readconcern, and readpref APIs ( Concerning moving those packages to the options package, it seems likely we'd run into some namespace collisions. It's not clear that the obviousness and discoverability improvements would outweigh the possibly awkward naming plus the added 1.x->2.0 migration pain. I recommend against merging these packages into the options package. Edit: Moving to "Needs Triage" with the recommendation that we close this as "Won't Fix". P.S. I think we should remove the "chainable setters" pattern from the options package (maybe retaining un-chainable setters in a few cases) in favor of just setting struct fields. However, not many people have complained about the usability of the "chainable setters" pattern, so it's not clear if removing it in Go Driver 2.0 would be worth the added migration pain. The motivation is mostly from the Go Driver team because maintaining all of those setters can be a lot of work. |
| Comment by Sam Kleinman (Inactive) [ 16/Apr/19 ] |
|
I changed the title of the ticket. Discoverability and documentation were definitely a struggle. I'm not sure there is a convention to get used to given the fact that there are multiple paradigms. It also renders the chainability less useful, because you have to construct the objects without chaining. |