Cindy's Segment - a Whimsical View of the World

Segment 1:
Lifestyles of the Rich and Object-Oriented
Or -
Not all Variables are created Equal

Imagine a world where all is clean and bright. Suddenly a call to glory goes out and in response, into this world comes a Mighty Class. As all good Classes do, the first thing that happens is that a ClassFile Castle is built to protect the good subjects of the class.

Now, this ClassFile Castle is built with a certain amount of storage space, of course. There is space in the Castle for class variable storage, where the Elite Static Variables can store their primitives or references. And there is space in the courtyard for literals to mill around and pool together.

There is a Castle Library where special information about related kingdoms is kept.

In addition, there is an area just outside the Castle, set aside for the Parliament, affectionately known as the Method Area. This area is a reserved place for all Royal decrees to be kept. Of course in JVMLand, the only behaviors that are allowed are those documented by royal decree. There are regular method decrees that dictate the behavior of the objects, and then there are the powerful Static decrees (also known as Static methods) that speak of things that only the Mighty Class can do.

Being a good and kind ruler, the Mighty Class allows his subject members to build Object Homes in the suburbs, outside of the Castle. The suburbs are called "The Heap". As each new object comes into being, a Home on The Heap is built, and these homes also have a certain amount of storage. So as to be fair, each and every home under the rule of this Mighty Class has exactly the SAME amount of storage, where each objects member variables can keep their primitives and references. The member variables in each Object Home is often called the objects fields, but I would call them storage closets.

And so the subjects were happy in their Object Homes, with plenty of space to hold their member variables and all of their behaviors dictated in the Method Area. And they have at their disposal all the resources of the ClassFile Castle.

But there is a dirty little secret going on in JVMLand. - - - Not All variables are created equal.

Sure, there are Elite Static variables being kept in the Castle, knowing that the Castle will probably last as long as all JVMLand. Yes, there are member variables snug in their Object homes, secure in the knowledge that as long as the Object Home is never completely abandoned, there will be a place for that member variable to live. But what no one ever talks about, what is whispered behind closed doors, is what happens in the Method Area.

When a Method is invoked, be it by one of the objects or by the Class itself, there are variables that are created automatically, on the fly. These poor creatures are never given a proper home. They are just assigned a slot on the stack, like a slave in a ship, where they toil away for the brief moment that their method is being executed, and then POOF!! They are tossed away like so much bit trash.

Oh the tragedy of it all! To have such a short existence, and to be treated with such distain. To be insulted by being called "Local Yokel"! To never have a classload or construction party, and so no one trusts you unless you are initialized right at the moment of your birth. What did they do to deserve that?

Not only is it bad enough that you know that you die as soon as your Method dies, but so often your scope of influence does not even last THAT long. If you happened to be a variable that is created in a block of code inside that Method, when the block is over, you are treated as though you were practically invisible. NO ONE knows that you are still there!!!!

Heck, if you are so unlucky as to be created in the initialization section of a For loop, when all the loops of that For stuff is over, your scope is over, you just sit around waiting for the end. Heaven forbid you should be created INSIDE one of the loops of a For loop, then your scope is only as long as the ONE loop.

Even your NAME is disposable. Heck, they figure that if you have no scope of influence, then they can't see you, and they can't get confused about who they are talking about, so what the heck, just use the same name over again. Bah!! No respect at all.

There is only one revenge that is sometimes available to the local variable. (Whisper this now) If they happen to have the same name as one of those high falutin' member or class variables or a parameter, during their short existence, they get to be "IT". If someone uses that name, it is the LOCAL variable that gets noticed. They get to over-shadow those big-shots with the stable life-styles.

And you know what, I think that they DESERVE IT.

So next time that you are thinking about how convenient it is to have Member Variables, remember the lowly Local Variable, and feel his pain.