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 [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
