launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Mon, Jul 26, 2010 at 12:48 PM, Julian Edwards
<julian.edwards@xxxxxxxxxxxxx> wrote:
> On Monday 26 July 2010 11:55:00 Jonathan Lange wrote:
>> On Mon, Jul 26, 2010 at 11:46 AM, Julian Edwards
>> <julian.edwards@xxxxxxxxxxxxx> wrote:
>> ...
>>
>> > I've seen a proliferation recently of people writing code like:
>> >
>> > class FlangeGrobbler:
>> >    @classmethod
>> >    def new(cls, ...)
>> >
>> > which completely bypasses the security adapter when returning new
>> > objects.
>>
>> It depends on how you do it.
>>
>> You can declare a class as providing an interface and then register
>> the class as secured utility for that interface. Grep for
>> classProvides in the code to see examples.
>>
>> The problem isn't how you write the class, it's how you invoke new().
>> You can still write new() as a classmethod and invoke it with
>> getUtility(IFooSet).new().
>
> I guess I'm struggling to see how @classmethod is useful then.  In fact, it's
> dangerous.
>

Why do you think it's dangerous?

> FWIW I don't think this way of doing things is any better (nor worse, though)
> than a utility class, is there a reason to avoid those?
>

There are a few:
  * An IFooSet is a poorly defined object, that doesn't do a very good
job of representing any actual thing in the system
  * It is actually more work and more boilerplate to have a second
class implement IFooSet (type it out!)
  * This extra work does not buy any meaningful separation of
concerns. It's very normal to have code that creates an object
together with the code that defines the behaviour of the object.

jml