On 4/1/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
> Bah! This is why adapters never get anywhere. My eyes glazed over 10
> lines ago. At their core, adapters seem like a simple enough concept,
> but whenever anyone starts talking about them we get what seems like
> overengineered examples that make my brain lock up.
Absolutely. On the other side of the coin, though, whenever I see
frameworks which use adaptation (for example, Twisted, or PEAK), my
immediate reaction is "wow, that's a really useful idea - why isn't it
used more?". Go figure.
> Couldn't an adapter protocol be as simple as a module with a dictionary
> in it and two methods?
Yes - see Alex's posting.
> # adapters.py
> registry = {}
> def register(adapter, resultdescr, *targetdescrs):
> for x in targetdescrs:
> registry[(resultdescr, x)] = adapter
> def find(resultdescr, targetdescr):
> return registry[(resultdescr, target)]
You've pretty much rewritten Alex's code here, so I'd say you have
understood the core of adapation pretty well.
Maybe we need someone to explain, in practical but not overcomplicated
terms, just why this isn't enough in itself, and why "real world"
adaptation systems seem so much more overengineered. (I'm sure there
are good reasons, but they need a bit of explaining!)
For example, all the "real life" adaptation systems that I am aware of
use interfaces. OK, Alex wants to divorce adaptation from interfaces,
because Guido isn't ready to bless an interface system yet, and Alex
doesn't want that to hold up adaptation. But maybe someone could
clarify:
- why all the adaptation systems use interfaces (what problems require them)
- how a non-interface based system would address these problems, or
how it would leave room to develop in a backward-compatible way to
address them.
To put it another way, we don't want something too simple in the
stdlib, and real-world implementations seem to imply that there's
something important lacking in the simple code you (and Alex) have
suggested.
> I'm assuming that sticking the above six lines in a file somewhere
> wouldn't be sufficient for some reason, but if not, why not? And what's
> the simplest possible proposal that would work?
Exactly. Alex seems to be saying that it would - or if he isn't, he
needs to develop his earlier post a bit more...
Paul.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
