Remove key from ComponentAdapter

I´m -1 on this. Do a search for usages of getComponentKey() and you´ll discover that many ComponentAdapter implementations actually use the key. (One example is the remoting one).

I'm still +1 on this but its really not a big deal. Most of the circumstances where an adapter is interested in its key actually couple the whole thing to a specific architecture. IMHO a key should be the responsibility of the Service Locator. Pico currently combines both Patterns (Instance Factory with DI, Service Locator) in one class and its fine but oftentimes a key is only required for the Service Locator and not for the actual Component.

I don't think a change is required before v1.0 (or perhaps not at all).

If we decide to do this (I doubt it) it won't be before post 1.0.

From one point of view, removing key is good - it's not a adapter business to know under which key it is registered.

From the other poiint , there is some logic behind the key (
explicit / implicit from class / assignable by component class ) - and this logic is resided in component adapters.

This means that logic must go somewhere.

But this is axactly the point: A key is a key and should not have whatever additional logic semantic. While a basic concept of pico is to use the class type as key, there should not be involved anything else. If the CA needs additional info, you can provide it with the ctor, like it is done for PoolableCA or DelegatingCA.

Keys can't go away unless we do some serious refactoring about how the container resolves Parameters. And that is by far more complex then just leaving the key as it is.

I changed my mind on this topic when I tried to get rid of the key. Its possible but to do so, you'll need quite some Parameter magic and thats not as easy as it seems at first.

Does having the key in the adapter incur a real problem for anyone? If so, what's the problem?

Basic architecture. To be reviewed later.

Perhaps this is a "to be reviewed for Pico 3?"