[Zope3-dev] Too many dependencies in zope.decorator

[Christian Theune]

Hi,

Jim Fulton wrote:
> 
> On Aug 24, 2006, at 7:32 AM, Christian Theune wrote:
> 
>> Hi,
>>
>> ZODB with Blobs uses zope.proxy. Recently I discovered that due to a 
>> refactoring, the semantics of a proxy have significantly changed and a 
>> new concept of a "decorator" was born.
> 
> I don't know what you mean.  The concept of decorator is not new and I'm 
> not aware that
> zope.proxy was changed in any way recently to support it.  The only 
> thing that changed
> was that descriptors in proxies are treated a little differently.

Well. I think we included zope.proxy on the original sprint, which is 
quite a while ago already, so the change might have happened in the last 
18 months.

>>
>> ZODB with Blobs needs the ability of a "specification decorator".
> 
> Does it really? Does anything in ZODB actually introspect interfaces?

Yes. It checks whether a storage implements IBlobStorage to find out 
whether to store a blob or not. One of the two storages that support 
blobs is a decorator (originally a proxy) that adds the blob methods two 
the base storage and declares that it implements IBlobStorage.

>> However, the zope.decorator depends also on zope.security, which in 
>> turns depends on many other things that depend on even more things. I 
>> didn't look up the final list, but as it's more than just one thing, I 
>> consider it to be too much for inclusion with ZODB.
>>
>> Would it be possible to split up the modules of zope.decorator in two, 
>> so ZODB could use the specification decorator without depending on the 
>> security decorator?
> 
> On some level this makes sense.  However, this  package was moved up 
> from zope.app and I think that more thought should have gone into how 
> that was done.
> 
> This package is really small.  It only defines three things: 
> DecoratorSpecificationDescriptor, DecoratedSecurityCheckerDescriptor, 
> and Decorator.
> 
>  Of these:
> 
>  - The Decorator base class isn't used.  It should be probably be 
> removed.  Unfortunately, this
>    will require a deprecation cycle.
> 
> - DecoratedSecurityCheckerDescriptor is only used in one place, although 
> it is redefined in zope.app.container.  It appears that it was copied at 
> some point and has fallen out of sync. :(
> I'm 99% sure that the zope.app.container should simply import this.  
> Then it will be used in multiple places.  I suggest that the definition 
> should move to zope.security.

Sounds about right to me.

> - Likewise, DecoratorSpecificationDescriptor is duplicated in 
> zope.app.container and has fallen out of sync.
> 
> I don't remember why these descriptors were duplicated in 
> zope.app.container.  I'm pretty sure that part of the reason was that 
> they are so trivial.  I'm not enthusiastic to have an egg and a ZODB 
> dependency for so trivial a package.
> 
> I suggest moving the DecoratorSpecificationDescriptor into zope.proxy, 
> sich depends on zope.interface already.
> 
> Of course, this would be for 3.4.

Jup. That's the release where blobs would go into anyway.

So, the todo list for this would be:

- remove copies of descriptors from zope.app.container
- move the DecoratorSpecificationDescriptoor to zope.interface
- move the DecoratorSecuritycheckerDescriptor to zope.security
- remove decorator base class
- remove zope.decorator

Each of the named steps requires a deprecation period.


-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development