On Monday 26 July 2010 17:28:01 Aaron Bentley wrote: > On 07/26/2010 12:13 PM, Julian Edwards wrote: > > On Monday 26 July 2010 16:24:33 Aaron Bentley wrote: > >> On 07/26/2010 11:10 AM, Julian Edwards wrote: > >>> On Monday 26 July 2010 16:01:31 Jonathan Lange wrote: > >>>>> I guess I'm struggling to see how @classmethod is useful then. In > >>>>> fact, it's dangerous. > >>>> > >>>> Why do you think it's dangerous? > >>> > >>> Because it allows someone to get hold of a new object that is not > >>> security wrapped. > >> > >> So does FooSet.new. What's the difference? > > > > None - that's exactly what I was referring to. > > So this means that FooSet.new is also dangerous. So why do you say that > a @classmethod is dangerous, if it's no more dangerous than a normal > method?
Argh, sorry I misread your last email. If there's no @classmethod on new() then you need an instantiated object. At that point, it's more likely that you've DTRT regarding <securedutility> rather than circumventing the proxy by calling the classmethod. So, if I understand this stuff right, you simply don't need the @classmethod if you call getUtility(IFoo).new() > >>> I don't know why you'd ever want to do that. > >> > >> It's very convenient in test code. > > > > Why? Why do you need to ignore security? > > Because I want to set up preconditions for my test that are much easier > to do by poking at internal state than by using the approved Interface. > Because it's sometimes easier or more precise to verify postconditions > by looking at internal state than by using the approved Interface. > > > If it is *really* needed, I would *much* rather see an explicit > > removeSecurityProxy() with a comment explaining why you need to remove > > the wrapper. > > Sure, explicitly removing the security proxy is clearer. I don't agree > about the need for a comment. Maybe I am jaded by bad Soyuz code, but I've seen removeSecurityProxy used all over the place because someone didn't understand the security. I therefore feel aggrieved when I see one, and demand a comment to explain it. :) > >> def FooSet.destroyFoo(self, foo) <- We can't check whether the user has > >> permission to delete this object at the zope level, because it's foo, > >> not self. > > > > I agree with all of this, except that I can't say I've ever been > > encouraged to have a delete method on a utility :) > > Having seen a delete method on a utility, I can only assume some people > have been. That's, umm, interesting. In a bad way. :( > > But still, we can do store.remove() anywhere and that's not checked. > > Indeed. It's not about making evil impossible, it's about helping > ourselves to avoid mistakes. Totally. That's why I'm advocating getting rid of @classmethod on that new() :) _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
