Proposal: Use opaque specifiers

[dgeb]

I closed #22 because it was a bit of a premature optimization. Without benchmarking, it will not be readily apparent the best strategy to use for typing the specifiers used to cache and access factories and instances. @krisselden would like glimmer-di to allow experimentation at a large scale, in real world applications.

In order to achieve this, @krisselden recommends typing specifiers as Opaque on public interfaces. We can then support custom dictionaries to be used internally to provide access to registrations and lookups based on these opaque specifiers.

[mixonic]

👍 I think we would like to see this for Ember when we adopt glimmer-di to replace the container. It will help us avoid creating serialized string versions of specifiers for addon cases.

For example when the following is invoked:

{{my-addon::foo-bar}}

I plan to implement a lookup in ember via an internal private API on the container:

container._lookupWithNamespace('template', 'my-addon::foo-bar');

This will avoid us adding public API to the current Ember container for the addon case. However it would be much nicer to pass this to the standard lookup interface with a partially complete specifier:

container.lookup({ type: template, rootName: 'my-addon', name: 'foo-bar' });

And this as a public API makes a lot more sense. If we add this functionality here in glimmer-di, when we use it to replace Ember's container the behavior can be introduced.

[mixonic]

In addition to passing specifiers to lookup and factoryFor, I would also like to see them passed to get/has in the module registry. The module registry used by Glimmer is optimized for the strings case (it just looks up the key in a list), however in ember-resolver the requirejs registry basically deserializes the absolute string just serialized.

Instead glimmer-resolver should accept the specifier object, and serialize to a specifier string internally. Ember-resolver would instead serialize into the AMD module paths.