[Interface-dev] Re: Interface and Adapter Demo

[Steve Alexander]

> Just an orthogonal thought: is it really *that* clumsy to implement the
> size as part of the file object? Or it is more of a design decision that
> for certain situations makes sense and for others not?

The problem comes when you want to provide a standard "size" API to 
someone else's file class.  You could fork their work, but that would 
mean maintaining your fork and merging fixes.  Alternatively, you can 
implement the extended functionality as an adapter.  You maintain the 
adapter, they maintain the file class.


> Does it make sense to have adapter-specific names, such as naming the
> attribute `file' in this case, given the improved understandability of
> the adapter's code, or is the adapter's code usual too short for it to
> matter? 

I've tried doing this from time to time, but I generally prefer to use 
'context'.  I have not found any problems understanding what 'context' 
is meant to be in most adapters.  It can get a bit confusing when you 
have a system that adapts adapters, and you're interested in 
context.context.  That's the only time I'd consider using a different 
name.  I think I'd keep the instance's variable called 'context', but 
alias it in methods where it would be confusing.


>>The third argument in the name of the adapter. Since we do not care
>>about names, we simply leave it as an empty string. 
>
> Conventionally (perhaps Zope-conventionally <wink>), what are these
> names useful for?

The name is used as a 'discriminator', to discriminate between different 
  implementations that provide the same interface.  This is a pattern 
that occurs quite often.

-- 
Steve Alexander