On Nov 9, 7:12 pm, Mark Shroyer <[EMAIL PROTECTED]> wrote: > I guess this sort of falls under the "shameless plug" category, but > here it is: Recently I used a custom metaclass in a Python program > I've been working on, and I ended up doing a sort of write-up on it, > as an example of what a "real life" __metaclass__ might do for those > who may never have seen such a thing themselves. > > http://markshroyer.com/blog/2007/11/09/tilting-at-metaclass-windmills/ > > So what's the verdict? Incorrect? Missed the point completely? > Needs to get his head checked? I'd love to hear what > comp.lang.python has to (anthropomorphically) say about it. >
Kinda wordy. Let me see if I got the point: - You already had a bunch of classes that did age matching on date time objects. - You were building a class that matched emails. - You wanted to reuse the code for age matching to do email matching (based on the message's age) - So you wrote a metaclass that replaced the match() method with a proxy that would either dispatch to the old match() method (if it was a datetime object) or dispatch to the new match() method (which matched based on the message's date.) Sounds Java-y, if that's even a word. Too many classes, not enough functions. You can tell you are doing Java in Python when you feel the urge to give everything a name that is a noun, even if it is completely based of a verb, such as "matcher". My opinion is that if you want to talk about doing something in Python such as matching, starting writing functions that match and forget the classes. Classes are for real nouns, nouns that can do several distinct things. What would I have done? I wouldn't have had an age matching class. I would have had a function that, given the datetime and a range specification, would return true or false. Then I would've written another function for matching emails. Again, it takes a specification and the email and returns true or false. If I really wanted to pass around the specifications as objects, I would do what the re module does: have one generic object for all the different kinds of age matching possible, and one generic object for all the email objects possible. These would be called, "AgeMatchSpecification", etc... These are noun-y things. Here, however, they are really a way of keeping your data organized so you can tell that that particular dict over there is an AgeMatchSpecification and that one is an EmailMatchSpecification. And remember, the specifications don't do the matching--they merely tell the match function what it is you wanted matched. Now, part of the email match specification would probably include bits of the date match specification, because you'd want to match the various dates attached to an email. That's really not rocket science though. There wouldn't be any need to integrate the classes anymore if I did it that way. Plus, I wouldn't have to remember a bunch of class names. I'd just have to remember the various parameters to the match specification for age matching and a different set of parameters for the email matching. -- http://mail.python.org/mailman/listinfo/python-list
