protocols, inheritance and polymorphism

[Donn Cave]

In article <tqadnT2kAIXJEj7cRVn-hA at rogers.com>,
 "Dan Perl" <danperl at rogers.com> wrote:

> "Donn Cave" <donn at u.washington.edu> wrote in message 
> news:donn-F6A9D8.11153623112004 at gnus01.u.washington.edu...
> > In article <YWKod.137814$HA.44609 at attbi_s01>,
> > Steven Bethard <steven.bethard at gmail.com> wrote:
...
> >> The point here is that I'm using isinstance here because I *know* there
> >> are objects out there that, unlike Bunch objects, may have 'attributes'
> >> not stored in their __dict__, and I *know* they might get passed to
> >> Bunch.update.  Since I can't appropriately support their use, I want the
> >> user to be notified of this (with the TypeError).
...
> > I don't really see that isinstance() was necessary in principle
> > here.  Not that it makes any difference to me, but it looks like
> > you created this problem by defining these semantics in Bunch
> > but failing to assign any identifiable attribute - we could in
> > principle make another unrelated class "quack like a Bunch",
> > but we'd have no way to inform your update function of this.
> 
> I'm not sure what you mean by an "identifiable attribute", but I think we 
> are going back to an issue I pointed out in another posting in this thread. 
> It makes a huge difference whether your code is something that only you are 
> using and changing during the next few weeks or it's an off-the-shelf 
> library that will be maintained and changed for years from now and will be 
> used by many clients.  What is "identifiable" to you (or even to someone in 
> the next cubicle) for the next few weeks may not be identifiable a few years 
> from now or to someone who downloaded your module from the web.

I wasn't really worried about people yet.  Perhaps I should have
said more simply that there is no attribute, period, for this.
Instead, in effect, the (base) class itself is used as that attribute.
That's an unnecessary limitation, because we can easily support
the required semantics from an unrelated class.

I must have missed your post, but I infer that you're claiming that
subtype polymorphism is easier to comprehend.  It wouldn't have
occurred to me.  I do think the current situation is a little
defective when it comes to reasoning about complicated code, but
I don't think subtyping is a very obvious way to define interfaces.
On one hand, it obviously isn't true that all objects that might
support an interface must inherit that support from a common base,
and it also isn't true that all objects derived from a common base
reliably support that interface.  How easy would it be to inherit
from "Bunch" and add some feature that confounds that function we
saw earlier with the isinstance()?

   Donn Cave, donn at u.washington.edu