[MERGE] Packs. Kthxbye.
robertc at robertcollins.net
Fri Oct 19 03:48:02 BST 2007
On Fri, 2007-10-19 at 09:37 +1000, Ian Clatworthy wrote:
> John Arbash Meinel wrote:
> > The only thing I don't like is that these functions are defined as regular
> > class functions, but have 0 dependency on self. So it would be nice if they
> > were @staticmethod so that you wouldn't have to instantiate a repository to
> > test them.
> I felt the same thing. I didn't raise it because I could see an argument
> where the results might be dependent on a repository policy setting say.
Two things combine:
- I consider static attributes accessed as 'self.method' as confusing
- I consider using Class.method for something that it is reasonable for
a subclass to change the behaviour to be artificially limiting.
So I don't use class scope for anything I expect a subclass to
reasonably be tweaking. And these methods fall in that category.
> > Though I believe you don't prefer staticmethods for some reason.
> It's fair to say Rob and I have different views on static methods. Must
> be my Eiffel/C++/Delphi/Java background but I do like them. :-)
> From a theory of constraints perspective, if code is only bound to the
> class and not every instance, that's a good thing. You can always
> refactor later to make it depend on each instance. Before then, a normal
> (object) method when a static (class) method is sufficient is YAGNI.
> Having said that, I don't think methods should be made static just
> because they can be in a given implementation. I like to think about the
> core object model and decide based on whether the method is logically an
> object or class related thing.
> BTW, I suspect Rob does the same thing but comes up with a different
> answer to you and I. :-)
We had this thread last week didn't we? A method that doesn't use self
is not inherently a static method. It can easily be tightly coupled to
transient data formatted in a particular structure, like these are,
which may be different in subclasses. It may only make sense to be
called when you have the object around. I think about
static/class/instance methods and attributes much more as what they are
associated too and what should be accessing them, changing them and
extending them than whether or not that code is *potentially* callable
If there is a use case for it without self, I would usually look for a
concept to factor out - a new class that they should belong to, because
there are previous few things that are not actually attached to some
group of related tasks.
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20071019/cf59fab9/attachment.pgp
More information about the bazaar