Guido van Rossum wrote: > On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: >>> Using @overloaded functions I would create an explicit class variable >>> which is the @overloaded adapter rather than trying to make the >>> interface also *be* the adapter. I would define the Interface class >>> like this: >>> >>> class InterfaceMetaclass(type): >>> # I hate anonymous metaclasses >>> def __new__(mcl, name, bases, dict): >>> # Give each class it's own registry >>> dict["adapter"] = overloaded(None) # set default_function to None >>> return type.__new__(mcl, name, bases, dict) >>> >>> class Interface: >>> __metaclass__ = InterfaceMetaclass >>> # No need for adapt and register methods here >>> >>> The registration would then look like this: >>> >>> Sequence.adapter.register(list)(PythonSeqAsSequence) >>> >>> and the invocation would look like this: >>> >>> print Sequence.adapter([1,2,3]).len() >> This looks reasonable enough, as the adapter comes for free and it >> avoids the problem of a __call__() in the Interface or its metaclass. >> >> But if I'm implementing an adapter for a certain type, I still can't >> make the returned object an instance of Interface (or I could, but it >> would inherit an adapter, which is useless), > > I'm not following. Why would an adapter ever return an instance of > Interface (which is just a token object, a reification of the concept > of an interface)?
An Interface is an abstract class that you subclass to make it a concrete implementation. If you have an adapter that adapts to the FooInterface why shouldn't it return a FooInterface object? >> so I would have: >> >> class Interface: >> def getitem(self, index): ... >> def len(self, index): ... >> >> Interface.adapter() which I have to call to do the adaption and >> >> class PythonSeqAsSequence: >> def getitem(self, index): ... >> def len(self, index): ... >> >> which implements the Sequence protocol, but shouldn't subclass Sequence. >> >> Somehow this feels awkward to me. > > Why would the wrapper class need to subclass the interface class? > > OTOH if you really like to express implementing an interface as > inheriting from that interface, what's the problem with inheriting the > adapter? The adapter isn't a class, it's either a fancy function or an object with a __call__(). Servus, Walter _______________________________________________ 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
