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
> 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
> 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
Zope3-dev mailing list