Comments on: I see your privates: How objects of the same class can share private variables in AS3

By: Paul

Paul — Sun, 26 Oct 2008 08:27:18 +0000

A private member variable may be accessed if a method is written for it, but it can not be accessed if no method exists for it. In other words:

var oJane:Person = new Person(‘Jane’, ‘Jane has a secret’);

// will error:
// trace(‘Jane is secure from direct member access: ‘ + oJane._secret);

// will succeed:
trace(‘Jane is not secure by method and design: ‘ + oJane.peekIntoDiary(this));

By: Tink

Tink — Thu, 09 Oct 2008 12:29:18 +0000

Kinda sneaky 😉

Thanks

By: Matt

Matt — Thu, 09 Oct 2008 03:05:07 +0000

The place I see this used most in Java is in implementing a .equals() method. Usually classes which provide their own .equals method will just go through and compare all the member properties of two instances. It would be awkward to implement without access to the other object’s private members.

That being said, I agree with the general sentiment that the behavior is non-obvious at first.

By: Darren

Darren — Thu, 09 Oct 2008 01:11:08 +0000

Josh, maybe the question is really what use-cases can you think of where this would be useful? The point of private variables is not to stop bad objects seeing/changing something they shouldn’t, it’s to stop bad coders seeing/changing something they shouldn’t. As Olivier alluded to above, if you have access to the class to put in your peekIntoDiary function, you could just as easily put in a getter function or make the variable public.

By: Olivier Allouch

Olivier Allouch — Wed, 08 Oct 2008 23:13:11 +0000

The tree structure is an excellent example.
And, you may not have noticed it because it’s sometime not simple to notice it, especially in Java where you don’t have the get/set types of functions, so no need for “_” before object arguments.

By: Mike Welsh

Mike Welsh — Wed, 08 Oct 2008 22:18:36 +0000

This behavior is pretty standard across langauges, but it’s definitely a surprise the first time you notice it. I know C++ and Java operate the same way. As others have pointed out, it makes sense and can be useful.

Another case would be for a tree or linked-list object, where you may have code to remove a node from the tree: _parent._child = null; _parent = null;

You don’t see it too often, but it’s definitely out there. Maybe people are just so accustomed to making public accessor methods for their private variables, that they end up using them even in these cases? 🙂

By: Josh Tynjala

Josh Tynjala — Wed, 08 Oct 2008 20:44:59 +0000

I have a question for the commenters who say this isn’t unexpected. If it seems logical to you, then why don’t I see developers taking advantage of this behavior more often? From the moment I started learning software development in 2001 to yesterday, over seven years later, I’d never seen anyone use this feature. Why not? Are there too few use-cases? Is it rare for one instance to have a reference to another instance of the same type? What is it?

It honestly seems very strange to me that I would never have encountered this in code written in any of the languages I’ve used before, whether ActionScript, Java, or something else. I’ve probably seen every other obscure feature of ActionScript used at least once. I’ve even seen undocumented features in AS2 used sometimes. Why not this one?

By: Olivier Allouch

Olivier Allouch — Wed, 08 Oct 2008 20:25:23 +0000

And to be completely honest, I have to say I also was surprise when I first discovered it 🙂
The OOP makes us see objects as independent individuals, and we tend to forget that OOP security is to protect from coders, not objects.
We’re just getting too virtual, I guess.

By: Olivier Allouch

Olivier Allouch — Wed, 08 Oct 2008 20:03:18 +0000

Actually, this behavior is completely standard and logical. Who decided this variable is private ? The guy that wrote that class. When he writes other methods of this class, he is home. If he can make this variable public, why couldn’t he read it when it’s private ? It’s his !

By: Josh Tynjala

Josh Tynjala — Wed, 08 Oct 2008 17:57:40 +0000

Thanks to the two Daniels for the interesting info. I guess I always just assumed that, using the terms the second Daniel mentioned, private means object-private rather than class-private. Like I said, it makes sense from a namespace point-of-view, but this is an assumption I've been making since my CS101 class in college (when I was using Java, which I've now learned has the same behavior). From my point of view, making private mean class-private rather than object-private makes objects less encapsulated, so I guess that's why I made the assumption. Anyway, interesting stuff. I'm sure this knowledge will come in handy at some point in the future.