On 9/15/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 9/15/05, Simon Willison <[EMAIL PROTECTED]> wrote: > > from django.models.blog import Blog, Entry > > > > Blog.get_list() > > Blog.get_object() > > Entry.get_iterator() > > I have a natural aversion to class methods like that. To me, it makes > more sense for a *module* to contain functions that return instances, > than for a *class* to have methods that return instances of that same > class. It's one of the things I don't like about SQLObject (which, of > course, has things that I do like -- but class-method use isn't one of > 'em). > > In the above example, Blog.get_object() returns a Blog instance, and > each Blog instance has a get_object() method. That feels awkward, > messy and ugly, in my opinion.
It does to me as well, but I think the benefits might outweight the costs in this case. It occured to me that it's not necessarily the module/class distiction that bothers me, but the naming: MyObj.get_object() vs. myobjs.get_object(). If this change goes through I might try something like from django.models.myapp import MyObj as myobjs I've never really used aliases though... I suspect there might be some gotchas there. Also, I don't know if the proposed change would help, but being able to use properties in my classes would be great. Joseph
