[SERVER-72646] The Options passed into AutoGet* constructors make it difficult to know what is available to the constructors Created: 09/Jan/23 Updated: 26/Jul/23 Resolved: 24/Jan/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
I think we've swung a little too far (over abstracted) pushing some (but oddly not all) of the AutoGet* constructor parameters into a vaguely named Options type. it's templated, even. I can't easily tell what parameter options I have access to while modifying code in the constructors – seems strange to go hunting for what parameters I have when they should just be listed in the function declaration. |
| Comments |
| Comment by Gregory Noma [ 10/Jan/23 ] |
|
Having an Options struct is useful for when there are multiple optional parameters. For instance without this sort of pattern, if the option you want to change happens to be the last one in the list of arguments, you'd have to specify all of the previous optional parameters even though you wouldn't otherwise need to. And this can add quite a bit of bloat to the callsites. I do agree that having the templating is a bit unfortunate, but it prevents us for having the entirety of the struct and its setters duplicated for the versions with/without secondary namespace support. However, once we have designated initializers in C++20, it seems more reasonable to me to just accept the duplication so that we can do away with the setters (along with the templating) entirely. |