Cindy's Segment - a Whimsical View of the World

Segment 2:
When relatives move in
Or -
Surviving your sub-classes

Kids these days!! I tell you , they are spoiled rotten. Look around and you will see what I mean. You would think that those sub-classes would be happy that they have their very OWN classfile at last, where they can express themselves as they see fit. But NO. That is not enough for them. When they go out to build their Classfile Castle, not a one of them can get along without an umbilical cord back to their Dad. Well, OK - it is more like a tunnel back to Dad's Classfile Castle "just in case" they have to lean on Dad. And boy do they use that tunnel.

Static Stuff in the Castle
Check it out. When Junior goes to build his Classfile Castle, he makes sure that he builds in storage for all the Elite Static Variables that he wants, but then if someone asks Junior about one of Dad's Static Variables, Junior just runs down that tunnel and gets the value from Dad's Classfile Castle and presents it as though it were his own. Heck he will even update the value of Dad's static variable - mind you - the one that is sitting in Dad's Classfile Castle, just as though it were his own. So then when Dad goes to use his very own Static Variable, well . . . you KNOW there is going to be trouble.

Of course, every so often Junior gets gutsy and builds a Static Variable in his Castle with the same name as one of Dad's Static Variables. Since he never confessed that he was getting the value from Dad, as far as all his friends know, Junior's Static Variable is the only one there. He just hides the fact that Dad has one with the same name. Heck - he often isn't so respectful as to even use the same TYPE for his Static Variable. Anyway - you have to be on to his tricks and know to use the magic words (that would be to say "super dot" ) before you request a Static Variable from Junior, to insure that you are getting at Dad's Static Variables for sure. Then again, you could do what the rest of the world does, and just request Dad's Static Variables directly from Dad by using his Classfile name in front of the variable, like "Dad.var" or whatever.

When Junior is being especially difficult he will intentionally pull rank with his Static Variables. So if Dad has blueprints for his subjects object houses on the heap that call for a variable closet with a particular name, Junior may just decide that he has to use that EXACT name for his Static Variable. Well, that means that every single one of Junior's objects that might have inherited a small closet from his Dad, well, it gets its meager closet hidden, just so some Royal Variable can use that name. It is bad enough when his Castle Variables go around hiding Dad's Castle Variables, but to hide the variables of the poor of his kingdom, this is difficult to put up with.

Same thing for his behavior. If Junior's Classfile just does not know how to do something, even after he has looked through ALL of his Royal Static decrees, he just runs down that super tunnel and finds the Royal Static decree that his Dad is keeping in Dad's method area, and follows those instructions.

Yes, he often hides Dad's Static behaviors that he should have learned with his own childish Royal Static behaviors. Royally rotten, that's what he can be. At least he can't use his Royal Static behavior methods to hide any of the behaviors that his objects might learn from his Dad (from his Dad's regular method decrees), like he can with variable closets. If he tries that the Justice Department would come down on him big time at compile time . Houses are one thing - but education for the masses is quite another thing.

Of course the reverse is true also. Junior's regular methods are way too feeble to override or hide one of Dad's Royal Static Methods. It can be good to have the Justice Department working for YOU.

Building bigger and better
So what happens when it is time to build an instance of Junior's out in the "Heap" suburbs? Not only do kids these days feel that their Classfile Castle has to outdo Dad's and all his static stuff, but all of Junior's object houses have to outdo Dad's too. FIRST Junior gets the complete blueprint for how to build one of Dad's houses on the heap, complete with all of Dad's variable storage closets, neatly labeled as having come from Dad's blueprint, and then Junior has to make HIS subjects houses bigger and better by adding his own variable storage closets labeled as having come from Junior's blueprints.

All of this wouldn't be all that difficult if Junior always showed some creativity and used his OWN names for his objects variables. But no, once again sometimes Junior thinks he knows better than Dad. Out of rebellion he sometimes uses the exact same variable name that Dad did and builds HIS subject's variable closet right in front of the one that came from Dad's blueprint. Of course to us innocent guys looking in, that effectively hides the variable from Dad's blueprint from sight, and Junior likes to say that his subjects didn't inherit such a variable from Dad. They simply couldn't have, because you can't refer to it with it's simple name can you?. But believe me, BOTH variables' closets are still built in there. Let's say that again - Yes, each and every subjects object home has a variable closet for both the Dad::var and Junior::var with the same name!! What a waste of floor space! And now if you want to look into the closet that came from Dad's blueprint you have to get FIRM and say that you insist on seeing the "super.var"!

Behavior Problems
I have already mentioned how important education is here in JVMLand. But I have to let you know that Junior seems to have found a loophole. The problem is that behavior is not built in stone like object houses with their variables are. Behavior is something that you have to DECIDE to do. And simple objects are always swayed by the last one to give them a good sales pitch.

So even though Dad has laid out some very good regular method decrees, and even though left alone, the masses would benefit from inheriting this knowledge of how to behave, and even though Junior can not hide those methods with his own Royal Static methods, he CAN invent his own regular method decrees and give them the same method names. AND since Junior is the last one to talk to the objects of his kingdom, yep - you got it, they always decide to override good common sense - with Junior's version of how they should behave in case that method is called. You know - Junior is shaping up to be a heck of a politician.

Moving in on Dad
Now comes the difficult part. Sometimes Junior crowds in on Dad's space. Well, we have already described how he can mess with Dad's Royal Static Variables, and play all sorts of hide and seek games, but he also sometimes abuses the hospitality of Dad's friends.

You know about TYPEs don't you? You know how all variable closets are stamped with a type which directs them at the Classfile to get directions from?

That is great if all of the variables with Dad's Variable types are holding objects that are subjects of Dad. You know:
Dad dadCloset = new Dad();

Well, when that variable is asked for the value of any other variable that is in it's object, FIRST the variable has to run to the Classfile for his type, and get the OK to give out that information. Since Dad's Classfile knows all the variables in his objects, Dad hands out the OK to get a "Dad::var" from the object and all is good. It even seems a bit of a waste to have to go get that OK from Dad. The same thing for Junior. Junior hands out OKs for "Junior::var" information. As long as everyone sticks to variables that are stamped with their own type, there is no confusion.

But, if Junior's subjects have a hidden Dad:X and also have a Junior::X they will give out whichever one that they get the OK for. If a Junior type is asking, then that type will go to Junior's Classfile and get the OK for a Junior::X. But when Junior butts in like:
Dad dadCloset = new Junior();
The type gets the OK from Dad for a Dad:X, (Junior's subjects HAVE a Dad::X built in and hiding behind the Junior:X), and the subject gives out the HIDDEN variable Dad::X. Go Dad!!! Suddenly it becomes clear why Dad enforces those rules.

Too bad it doesn't work that way with behavior. But like I already said, behavior is not built into the object houses, it is decided on at the last minute. If a Junior object is sitting in a Junior type and a method is requested, the type runs to the Classfile and finds the behavior for the method in Junior's Method area. If it can't find it there, it sneaks down that tunnel and gets the behavior from Dad's method area.

If the Junior object is sitting in a Dad type and a method is requested, the type goes to Dad's Classfile to get the OK for the method. If Dad HAS that method, he will give out the OK, and THEN Junior will convince the subject to use HIS version instead. Unless of course you use the magic words "super dot" when calling the method.

Well, at least if one of Junior's subjects can not GET the OK for a method from Dad's Classfile, Junior can't use his own methods, even if he has them, until he gets his butt into his own darn variable type.

Did I mention that that tunnel is one way. Too bad Dad can't sneak down and swipe whatever behaviors he wants to learn from Junior.

Dare to discipline
Well, you can see that Junior could turn out to be a problem. It takes a firm hand to guide him properly. So there are some things that you just MUST make sure that you enforce.

Do NOT let them get at your private Stuff! Your privates are your own business and that is that!

You must be Firm and INSIST that they use the return type that you have used if they insist on overriding your methods. It really is not so bad if their behavior strays from the path, as long as they return correctly.

NO WAY that they should be able to throw extra exceptions in their methods after they have overridden Dad's, and expect Dad to pick up the tab! Just say NO.

If you just be sure to add these elements of discipline to your relationship with the kids, and try to understand them - well, you will just LOVE them - in spite of their wayward ways.

Copyright 2002. Cindy Glass. All rights reserved.

Graphics by Pauline McNamara and Stephanie Grasson

Next month - "Stereotyping and pidgeon -holing" - or "When is an Interface too tight"