Mike Meyer wrote: > "Carl Banks" <[EMAIL PROTECTED]> writes: > > > Say you have a suite of functions, all of which are called by some main > > function and each other, and all of which need to access a lot of the > > same data. The best, most straightforward way to do it is to have the > > common data be a local variable of the main function, and nest the > > suite inside it. The other way to do it, passing around a common data > > structure, add complexity and hurts performance. > > The third way to do it is to make the thing a class.
Which is kind of the same thing as passing a structure around, only with a somewhat more convenient syntax. But yes. > Make all the > functions methods of the class, and all the data instance > variables. You may well want to make the main function the __call__ > method of the class. In an OO environment, this may be a better, more > straightforward way than nesting fnctions. There are good reasons for sometimes using a class, but straightforwardness is, IMHO, not one of them. You're writing a function (in the abstract sense: you are creating an entity that you call with input to get output, and that has local storage that doesn't need to exist afterwards). Is it more straightforward to implement an (abstract) function with a function object (i.e., the object that was designed exactly for that purpose), or with a class (designed for a different purpose: to create new types)? I'd definitely go with the former. Implementing an (abstract) function as a class obscures its purpose. I agree that there are many times when a class is a more appropriate implementation of an (abstract) function, such as if your suite of subfunctions has to rebind common variables, or if your (abstract) function has so many return values it's better to define it as a class and have the caller refer to the attributes. However, I'd say this comes at the expense of straightforwardness (or, rather, it exchanges one sort of striaghtforwardness for another sort judged more important). As for implementing an (abstract) function as a class just because you're in an OO environment: that's just thinking backwards. "OOP is the shizzle so I'm going to implement everything as a class," is simply the wrong way to think. There's a reason OOP is the shizzle: because it's very often a good representation of the problem. But it isn't always. And when it isn't, and when a better way exists (as in this case), you should use the better way, even in the highly OO environment. OOP is a means, not an end. -- CARL BANKS -- http://mail.python.org/mailman/listinfo/python-list
