> > On Sat, Nov 28, 2009 at 9:39 PM, Steven D'Aprano < st...@remove-this-cybersource.com.au> wrote:
> > Removing code redundancy is all very well, but beware of turning into an > >> architecture astronaut: > >> > http://www.joelonsoftware.com/articles/fog0000000018.html > >> > There is such a thing as over-generalisation -- if you're having to > >> struggle to get the abstract code working abstractly enough, you're > probably over-generalising. > That's an interesting article, but I don't really understand what the author's point is. It's okay to generalize, but don't make a big fuss about it? It's okay, but don't do it anyway? I honestly can't tell. He seems to be criticizing a lot of good products (like Java), not because they are generalizations exactly, but because there is too much hype surrounding them. > Anyway, I'm not generalizing for the sake of generalizing. I'm generalizing because it appears to be a logical solution to a _specific_ problem, namely the fact that nearly identical class definition code was being repeated in several classes with only a few minor details difference. If it were a regular processing problem, a function would be created to do the repeated work, but since the redundancy occurs before any processing has occurred in the traditional sense, the redundancies have to be collected in a _different_ way. > Now that I think about it, though, Python 2.6 and above support decorators on classes (an example of generalization, by the way). The metaclass code could be moved almost verbatim to a decorator function which could then be used on classes that needed it. It would still be a mess, though. > hm...actually, inhahe's code made me realize that the metaclass could be cleaned up even more than I originally thought by the proposed syntax because it could be used for naming functions as well as attributes. ;^_^ > > > > The code worked very > >> > well, and allowed for the pattern to be added to any class by using a > >> > single, short line of code (something along the lines of __class_attr = > >> > { key: value }). Not only that, but the metaclass code itself was > >> > comprised of less than a screenful of code after docstrings and comments > >> > had been removed. However, the code was (and still is) very difficult to > >> > follow simply because of the way getters and setters had to be used to > >> > generate the methods and properties. > >> > That's good evidence that you've over-generalised. > I don't follow. Could you please be more specific? (no pun intended)
-- http://mail.python.org/mailman/listinfo/python-list