- Start Date: 2015-04-09
- RFC PR: https://github.com/emberjs/rfcs/pull/46
- Ember Issue: https://github.com/emberjs/ember.js/pull/11440
Fully encapsulate and privatize the
Registry classes by
exposing a select subset of public methods on
Registry classes currently lead a confusing life of
semi-private exclusion within Ember applications. They are undocumented
publicly but not fully private either, as knowledge of their particulars is
required for developing both initializers and unit tests. This situation has
become untenable as the new
Registry class has been extracted from
Container, and the complexity of their usage has grown across
We can bring sanity to this situation by continuing the work started at the
Application level to expose methods such as
inject from the
Registry are fully private, their
architecture and documentation can be cleaned up. For instance, a
Container can freely reference its associated
_registry, as it can be assumed that only framework developers
will reference this property.
Application will expose the following methods from its internally maintained
registerOptions- mapped to
registerOptionsForType- mapped to
ApplicationInstance will also expose the the same methods. However, these
methods will be exposed from its own internally maintained registry, which
has the associated
Application's registry configured as a "fall back". No
direct path will be provided from the
ApplicationInstance to the
ApplicationInstance will also expose the following methods from its
internally maintained container:
ApplicationInstance will cease exposing
Application initializers will receive a single argument to
ApplicationInstance initializers will receive a single argument
Registry will be made fully private and documented as
Container will freely reference its associated
registry rather than
will provide an
isolatedApplicationInstance method instead of an
isolatedContainer for unit testing. A mechanism will be developed to specify
which initializers should be engaged in the initialization of this instance.
In this way, we can avoid duplication of registration logic, as is currently
done in a most un-DRY manner in the isolatedContainer.
This refactor will require maintaining backwards compatibility and deprecation warnings until Ember 2.0. This will temporarily increase internal code complexity and file sizes.
The obvious alternative is to make
Registry fully public
and documented. An application's registry would be available as a
property. An application instance's container would remain available as
We could still pass an
Application into application initializers
ApplicationInstance into application instance initializers.
If this alternative is taken, I would suggest that
inject in favor of calling the equivalents on its
Regardless of which alternative is chosen, we should ensure that the public aspects of container and registry usage are well documented.
Are the public methods listed above sufficient or should any others be exposed?
What mechanism should be used to engage initializers in unit and integration tests? Should test modules simply have an
initializersarray, similar to the current
Given the semi-private nature of containers and registries, we may not need to worry about semver for deprecations. However, we should be good citizens and properly deprecate as much as possible. Some real world use cases in initializers will no doubt be a surprise, so we need to tread carefully.