Stephan Richter wrote:
>>>I am -1 on moving <implements> out of the class directive. I am impartial
>>>on the factory subdirective, since I never use it. I think factories are
>>>failed experiment, btw, but that's another story.
>>>
>>>If <implements> is moved out than what's the point of having a class
>>>directive in the first place.
>>
>>Making security assertions about the class. This would be the only thing
>>that <class> would be used for, ultimately reducing its functionality to
>>one thing.
> 
> 
> Then why don't you call the directive "<secruity>"?

Or <classSecurity>, because it's class-based. Good idea.

> Or even better, get rid of 
> it altogether and have simple directives for "<allow>" and "<require>".

Perhaps. Of course, practicality sort of wins here because we already
have top-level <allow> and <require> directives for making assertions
about modules.

> I am still -1 on removing implements from the class directive. 

Why? I respect the vote but so far I haven't heard a reason for it.

> I think they have another purpose. They group the declarations for one thing 
> together, which makes it easier to read.

True. Which is why I would defend class/require and class/allow as
subdirectives (instead top-level ones). The reason why I'm not defending
class/implements is because I'd like to consolidate.

Especially in Five, but I can imagine also in other projects, you'd like
to declare interfaces on classes without configuring their security.
Five invented five:implements for this. In Zope 3 this is not possible.
Also, neither in Zope 3 nor in Five it's possible to declare an
implemented interface on a function (I actually have use cases for this,
of course I could deal with them differently, but a uniform way would be
nicer).

Philipp
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to