launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 26 July 2010 17:57:48 Aaron Bentley wrote:
> On 07/26/2010 12:42 PM, Julian Edwards wrote:
> > On Monday 26 July 2010 17:28:01 Aaron Bentley wrote:
> > 
> > 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.
> 
> Okay, point taken.  Though the scope where you can import Foo in order
> to call Foo.new is already pretty restricted due to the importfascist.
> 
> > So, if I understand this stuff right, you simply don't need the
> > @classmethod if you call getUtility(IFoo).new()
> 
> The @classmethod means that you can register the class Foo, not
> instances of the class Foo, as a utility, which means that you don't
> need an instance of Foo in order to call Foo.new.

Ahhhh, now I see why it has it.  I didn't see that it was registering the 
class rather than the instance, so this makes much more sense now.

> If you don't have an @classmethod on Foo, then you need an instance of
> Foo in order to call Foo.new on it, and that's crazy.  So no classmethod
> means you need to hang new() off a FooSet class instead of Foo.
> 
> Personally, I've always thought it was strange that we have to
> instantiate these FooSet objects, since they don't have any state.  If
> we keep on using them, I'd recommend using @classmethod/staticmethod on
> them :-)

I don't think it's that crazy if you're using utilities.  They're lazily-
instantiated (or supposed to be!) singletons and we don't store any state in 
them either, so they're super lightweight.

We could even rename them to XXXFactory utilities to make it obvious what's 
going on, and maybe move their existing collection querying methods to 
classmethods on the model object (getXXX etc).