This repository has been archived by the owner on Sep 14, 2020. It is now read-only.
Refactoring [1/3]: renames for better terminology #209
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.
Code refactoring (part 1 of 3): terminology fixes and look-ahead alignments.
Description
This PR is purely for renaming the classes and methods (massive, but simple) — a part of the code refactoring needed to extend Kopf with the startup/cleanup/(re-)authentication background activities.
Adding "activities" requires some terminology corrections, specifically naming the "resource"-related causes/handlers/registries as such.
Now: they exist as the only possible form of causes/handlers/registries. Adding the activity-specialised classes/methods in addition to generic-looking but resource-specialised classes/methods will create a confusion.
Briefly:
custom_object_handler
->resource_handler
(to be paired withactivity_handler
).SimpleRegistry
->ResourceRegistry
(to be paired withActivityRegistry
)GlobalRegistry
->OperatorRegistry
(for the legacy method extraction & deprecation later)...._event_watching_...
->..._resource_watching_...
(causes, handlers, registries)...._state_changing_...
->..._resource_changing_...
(causes, handlers, registries).get_state
->get_essence
(a leftover from Annotate all the code with the types #200: the "state" word is reserved for the reactor's state persistance, and should not be used for the resources' minified bodies (now: "essence")).There are NO behavioral changes. The public interfaces are kept unmodified. These are the internal changes only.
Some of these renames were introduced in #202, and never were released yet (despite merged to master), so it is safe to rename it again without breaking the public interfaces of any Kopf version.
Types of Changes