Open sandstrom opened 5 months ago
Happy to discuss this in more detail, and elaborate more.
I'd definitely like to see a bit more intentionality here.options
feels like this sort of "grab bag" of information, and I certainly agree that it increases the cognitive overhead when reading through it.
So in that sense, I'd also push more towards your second proposed option.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Still relevant!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Not stale
Is there an existing issue for this?
Is your feature request related to a problem? Please describe
Right now options are used both internally and externally. For example,
:block
and :association` are blessed options with internal purpose.They are sometimes 'scrubbed out' for example this line in
AssociationExtractor
:This increases the risk of colliding with user-defined options, and also make the internal code slightly harder to follow/modify.
Describe the feature you'd like to see implemented
I would separate the two sets, in one of two ways:
internal_options
andoptions
, and keep things such as:block
in the internal set, or@field_block
(see example below).I'd prefer the second way, but (1) would at least be an improvement over the current state.
Describe alternatives you've considered
No response
Additional context
No response