On Oct 31, 8:26 am, Anand <[EMAIL PROTECTED]> wrote:
> On Oct 28, 1:16 am, Pradeep Jindal <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Friday 26 Oct 2007 6:21:57 pm Anand wrote:
>
> > > On Oct 26, 5:31 pm, "Pradeep Jindal" <[EMAIL PROTECTED]> wrote:
> > > > Can you tell any specific use case for doing this?
>
> > > I have many implementaions of a db interface.
>
> > > SimpleDB - simple implementation
> > > BetterDB - optimized implementation
> > > CachedDB - an implementation with caching of queries
> > > RestrictedDB - implementation with permissions
>
> > > Now, I want to combine these implementations and use.
> > > Typical use case scenarios are:
>
> > > db = RestrictedDB(CachedDB(SimpleDB()))
> > > db = RestrictedDB(SimpleDB())
> > > db = RestrictedDB(BetterDB())
> > > db = RestrictedDB(CachedDB(BetterDB())
> > > db = CachedDB(SimpleDB())
> > > etc..
>
> > I agree with Duncan. According to me, this should be called Delegation
> > rather
> > than inheritance. And delegation should work without any conflicts of
> > identifier names and all that. I think, it should be all about several
> > objects implementing a protocol (interface) and that should work cleanly.
>
> I don't think so. It is not as simple as delegation.
>
> In the example that I gave previously, call to self.say in A.foo
> calls B.say not A.say, which I think is not possible with delegation.
Let me explain what I meant, its all about several objects (e.g. "a")
implementing a protocol, in your case the "say" method, and some
object (e.g. "b") extending those objects by adding some more
functionality but requiring that those objects, that it extends from,
follow a specific protocol ("a" must have say method). Also note that,
"B" or "b" is partial implementation of what its meant for, I mean,
calling "b"'s "say" will not work if "b" has not yet extended from "a"
or any other object implementing the same protocol.
Less time, can't get into more details. Bye for now.
Thanks
-Pradeep
--
http://mail.python.org/mailman/listinfo/python-list
