[ZODB-Dev] Implementing Storage Decorators

[Jim Fulton]

On May 4, 2007, at 3:14 PM, Dieter Maurer wrote:

> Jim Fulton wrote at 2007-5-4 14:40 -0400:
>>
>> On May 4, 2007, at 2:33 PM, Dieter Maurer wrote:
>>
>>> Jim Fulton wrote at 2007-5-2 11:52 -0400:
>>>> ...
>>>> I think I still rather like explicit, but I'm on the fence about
>>>> which approach is best.  What do other people think?
>>>
>>>> From your description, I would use a subclassing (and forget about
>>> proxy and copying).
>>
>> That would be a nightmare, on multiple levels:
>>
>> - All of the separate implementations would become tightly coupled,
>> which is what happens with inheritance.
>>
>> - Either someone would have to create classes for the various
>> permutations of features, or consumers would have to mix and match
>> multiple classes to get what they want and sort out the variate
>> internal implementation incompatibilities.
>
> Your decorators would become mixin classes
> and the final classes would list the features they like

So the second case above.  As I said, inheritance causes tight  
coupling.  Mix in classes can work when the features provides are  
truly independent.  That would certainly not be the case here.   
Trying to combine multiple storage implementations in a single class  
would be a real mess.

> -- simpler
> than ZCML binding together...

There's no ZCML involved here, although there would likely be ZConfig  
files.  People would want to be able to combine storages in their  
configuration files.

> Of course, some features may not play well with one another.
> But, that will make problems also with proxies or copying...

All of the examples I mentioned can be handled very well with a  
decorator model.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org