On 4/2/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> This is where I've always come unstuck in thinking about adaptation - actually
> using C++ and VB6 has persuaded me that implicit type conversions are
> generally evil, and there doesn't seem to be anything in adaptation that makes
> it the exception.
On the face of it, there's nothing implicit going on. There has to be
an explicit adaptation call. However, I agree that systems that make
extensive use of adaptation can seem to end up in a situation where
data seems to magically appear without anybody providing it. Black
magic of that level seems to me to be a clear abuse, though. The
problem may be that there are no "good" uses of adaptation to compare
against, just because it's easy to hand-code your own alternative in
straightforward cases, so by the time you're ready to add a dependency
on someone's external adaptation library, you're already part way to
the dark side...
If, for example, basic ideas like copy_reg, __index__ and __iter__
were framed in terms of adaptation, people would maybe be less likely
to see it as deep magic, where it becomes a pervasive theme of your
framework, and triggers the "everything is a nail" reaction...
> OTOH, there may be a hidden assumption among the fans of adaptation that
> adaptation to a mutable interface should never add state to, nor copy the
> state of, an adapted object. Any mutation made via an adaptor would be
> reflected as a mutation of the original object. Adaptation to immutable
> interfaces would always be fine, naturally. If that's an unwritten rule of
> adaptation, then:
> 1. It addresses the main evil of implicit type conversion (hidden state)
> 2. It needs to become a *written* rule, so that anyone writing a stateful
> adapter can be duly admonished by their peers
I don't know if that's an "unwritten rule" as such - but I can barely
imagine what you're describing as unacceptable (adaptation to a
mutable interface which adds or copies state). It just seems like a
stupid thing to do (or at least, not at all what adaptation is about).
But maybe that's what you mean by a "hidden assumption".
Regardless, I'd have no problem with a style guide, or good practice
document, stating that this is what adaptation is about, and stateful
adapters are bad practice. (That's just my opinion - better check this
with people who make heavy use of adaptation). But to me it feels like
labouring the obvious - along the lines of explicitly prohibiting
metaclass or decorator abuse.
> The other thing is that it makes more sense to me for there to be a
> per-protocol type->adapter registry, rather than a global registry with tuples
> of source type/target protocol pairs.
What difference would that make in practice?
> Secondly, given that each framework is likely to be defining the protocols
> that it consumes, I don't see the problem with each one defining its *own*
> adaptation registry, rather than having one mega-registry that adapts
> everything to everything.
[...]
> Then the role of an adaptation module in the standard library would be to
> provide a standard API for per-framework registries, without also providing a
> mega-registry for adapting everything to everything.
Not an unreasonable idea, but how valuable would it be in practice?
Alex's proposal allowed for explicitly specifying a registry, while
still having a default "central" registry. For 99% of use, I'd suspect
that people would not bother with a special registry. And if protocols
were defined via some "interface" approach (like zope.interfaces and
PyProtocols do) then encapsulation is taken care of by uniqueness of
types/interfaces. I know interfaces are outside the scope of what's
being proposed right now, but one of their benefits is that they *do*
solve this problem. Structured strings naming protocols
("org.python.std.index" or whatever) do this as well, but without
language support.
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
