Open rahulporuri opened 5 years ago
In personal discussions, senganal mentioned that it might be a good idea to invalidate the cache whenever new adaptation offers are registered with the adaptation manager.
...it might be a good idea to invalidate the cache whenever new adaptation offers are registered with the adaptation manager.
Not just a good idea, but essential to the proper functioning of the code.
You would need to have different caches for different adaptation manager instances, and you would need to correctly handle cases of dynamic adaptation (eg. you could imagine an adapter that given Class A sometimes produces Class B or Class C, which both support the protocol, but perhaps in different ways).
@corranwebster just to be clear, the cache can simply be a mapping of type -> interface associations. The cache doesn't need to provide the know the relevant adapter to convert a type to interface.
My thoughts are purely driven by #455 where we only need to know whether a type supports an interface. We don't need to know how it is supported, which adaptation offer/adapter provides the support etc.
Ah, I see, you're only going to check if you can adapt, not any other part of the result. Then this seems reasonable, although you probably want to use sets of classes rather than lists of classes in your hypothetical data structure.
Currently, the adaptation manager does not maintain a cache of protocols and known classes which support the protocols. This leads to issues like #455 where instances of the same class are repeatedly run through the adaptation manager machinery to determine whether or not the class/instance supports the protocol.
The cache could simply be a dictionary -