Rename the "component setup" term to "component usage" #83
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This (so far draft) PR considers the idea of renaming the "component setup" term (which is used for naming a hierarchy of classes, which are used as compont class's companion objects) into the "component usage" term.
The reasoning behind this renaming proposition:
The term "setup" can feel misleading in some aspects. While we imply "setup" to be a synonym (or a metaphor) for "embedding an instance of component into the composition":
First, it doesn't feel to match the notion of "embedding an instance" nicely: it's not a general term encompasses the notion of "embedding an instance" as one of its variants, but the one that pretends to be specific and, being that, still feels to be somewhat off.
There can be more scenarios than "embedding an instance" (e.g.
MessageForm
also provides an extracreate
function for creating a form's instance), or even some components that don't include the "embedding an instance" scenario at all (e.g.ConfirmationDialog
is currently just used imperatively, and its companion object contains the respectiveask
function for that purpose).Thus the "setup" metaphor doesn't match the entire variety of usage scenarios in general.
The term "usage" on the other hand:
Still as concise so the names are equally compact.
Represents a general term that reflects the idea that this object introduces a way of how a component's class can actually be used (an entry point to using the component).
It also appears to suit both usage scenarios: when components need to be used by declaring their instance, and when they need to be used with some imperative API (e.g. like
create
for forms, or theopen
andask
APIs of various dialog components).