[Tutor] What is a "state variable"?

[Walter Prins]

On 11 November 2010 20:11, Richard D. Moores <rdmoores at gmail.com> wrote:

> The term comes up in the 2nd section of
> <http://personalpages.tds.net/~kent37/stories/00014.html<http://personalpages.tds.net/%7Ekent37/stories/00014.html>
> >
>
> <http://en.wikipedia.org/wiki/State_%28computer_science%29> didn't help.
>
> k = 23
>
> Is k then a state variable in that its state is 23? What sorts of
> variables are, and are not, state variables?
>

My $0.02 worth:

Firstly, the original page somewhat conflates classes and objects, although
this is common and usually the author's meaning can be inferred if one
understands object orientation properly and understand that both classes,
and the objects (instances) made from that class can have their own state.
Usually however people mean that objects (instances) have state variables,
even when they talk about classes. The trouble is that classes are
themselves objects, and can in fact have their own stat.  But, ignore that
for the minute.

So what is state? Well, your toaster has a "powered" state, it's either "on"
or "off".  If you were to create a class to model/represent a toaster (e.g.
from which you can create toaster instances), each of them would be either
"on" or "off".  Now, how would you implement this?  Well, by using a
variable to store what the current state of the toaster object's supposed to
be, e.g. maybe a boolean variable calld "powered_on" that is true when that
instance is supposed to be on, and false otherwise.

So then, any variable (field member of an object) that serves to record what
state an object instance is in, can legitimately be called a state
variable.  Now, the point the original article was making was that if you
have several pure functions (e.g. structured programming style) where the
only scopes available is either full on global or local to each function,
then *every* variable that a function might modify/mutate must be passed to
it as a parameter.  Consequently, if a set of functions collectively operate
on a bunch of data structures, they have to pass all the data to each other
all the time.  This is unavoidable in pure structured languages, except if
you use global variables, which is frowned upon.  Enter object orientation:
If instead however, you turn those functions into a class, you can then
instead have them all "share" the same variable(s) that's commonly visible
to each of them due to paramter passing as shared "state" variables of the
object they belong to, hence removing the need to pass the variables around
all over the place.

To be clear, it might be argued that *any* variable forming part of an
object is by definition some sort of state variable for that object, since
objects having different values for their data members will by definition be
in slightly different states.

Finally, the notion of state is commonly used in computer science, so is
formalised there, some of those formalisms are mentioned in the other page
you reference.

Hope that helps somewhat, ask if that's not clear please.

Walter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20101111/f14b0b2f/attachment.html>