using "private" parameters as static storage?

[Luis Zarrabeitia]

Quoting Joe Strout <joe at strout.net>:

> Hi Luis,
> 
> > A lot of languages have ditched the "concept" of a static variable  
> > on a method (how do
> > you parse that sentence, btw?) in favour of using encapsulation.
> 
> A static variable IS encapsulation.  Encapsulation happens at many  
> levels: module, class, instance, and (in languages that support it)  
> method.  A static local variable is simply the finest level of  
> encapsulation.  (Well, actually you could go one finer in some  
> languages and have block-level static scope.)

But, at least in C++, its really confusing. The 'static' word is reserved on C++
for more than one meaning, but I'll agree that it is a C++ problem and not a
problem with the concept. I wish I remembered how and if LISP did it, though.
Being LISP, I'd guess their implementation is also based on closures.

> > * With closures:
> >
> > ===
> > def myfunc():
> >    pseudo_static_list = []
> >    def real_function(args):
> >         pseudo_static_list.append(args)
> >         print pseudo_static_list
> >    return real_function
> > myfunc = myfunc()
> 
> That's interesting -- I'll need to study it further before I really  
> understand it, so thanks very much.  (That's why I ask these  
> questions; I'm hoping there is some Python feature I haven't yet fully  
> grokked which applies to the problem at hand.)

Well, I love closures :D. And decorators.

> No, just adding an instance attribute to the class the method is  
> already on does not give you the same semantics at all, unless the  
> class happens to be a singleton.  Otherwise, each instance would get  
> its own cache (or count or whatever -- there are several different use  
> cases I've seen for this), rather than a shared one.  Sometimes that's  
> acceptable, but often it's not.

Not necesarily.
One of the things I dislike about 'static' is precisely that it would define the
variable's lifetime as 'forever, everywhere'. But as you say, that may not be
the only answer. You could need 'as long as _this function_ lives' (python gives
you closures for that), 'as long as this object lives' (instance attributes),
'as long as this object's class lives' (class attribute), 'forever' (a global,
or a class attribute of a fixed class, that would be like a global but with a
namespace).

Btw, you can yank a function out of an object and put it on another, if you need
your counters to survive that, use closures, if you need your counters to die in
that case, you'll have to stick with class or instance attributes.

> As noted before, the obvious solution in this case is to use a module-  
> or class-level variable, prefixed with an underscore.  That's not  
> horrible, but I wanted to explore possible alternatives.

Fair enough.
 
> >> I understand very well when data should be stored as instance data,  
> >> and when it
> >> should be instead tucked away as static data within a method.
> >
> > OT: Please enlighthen me. I didn't grew with C, and even when I saw C 
> > ++,
> > instance variables made a lot more sense to me that 'static'  
> > variables.
> 
> Maybe a couple examples will help:

Thank you.

 
> > I hope mine was more palatable to you.
> 
> Yours was tasty indeed, thanks very much!

/me smiles.
 
-- 
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie