On Dec 1, 2009, at 8:21 AM, Martijn Faassen wrote:
Hi there,
I'd like to summarize the options I've seen appear in the discussion so far.
We have the following options:
1) introduce a new method, such as "instance()" or "lookup()" on instance. It unifies utilities with adapters. We can make it do whatever we want without worrying about backwards compatibility.
2) introduce several new methods that distinguish between utility and adapter lookup. We can make them do whatever we want without worrying about backwards compatibility.
3) call the interface, which unifies adapter and utility lookups. Use tuples for multi adaptation. We think could make this work without *too* much backwards compatibility issues (pending research on how prevalent tuple adaptation really is). In the long term we can even map out a deprecation strategy that can smoothly migrate us to a "multi argument" approach.
4) call the interface, which unifies adapter and utility lookups. Use multiple arguments for multi adaptation. The backwards compatibility obstacles are largest here as we already have the "default" argument. We'd need to introduce multiple "modes" to selectively upgrade.
You are leaving out the variants of 3 and 4 that allow calling the interface to support multiadaptation, but do not unify utilities. My impression is that I am not the only one who is not pleased with the proposed unification of utilities and adaptation. My impression is that we are nearing consensus on the variation of 3 that does not include utilities. Gary