lambda closure question

[Carl Banks]

Mike Meyer wrote:
> "Carl Banks" <invalidemail at aerojockey.com> 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