Comments on: Packages are actually namespaces in ActionScript 3

By: James Bond

James Bond — Fri, 23 Jul 2010 19:12:30 +0000

Right — I have experienced the same thing (can’t synthesize the namespace or QName objects that getMemberNames returns). There is one line in the docs that hints that the “special” namespace that is used to get at the private and otherwise inaccessible member variables is not utterable. I’m using this technique right now to do some object reference graph traversals, so it’s highly beneficial in specific circumstances.

By: Josh Tynjala

Josh Tynjala — Thu, 22 Jul 2010 19:29:56 +0000

James, I confirmed that the QName returned from flash.sampler.getMemberNames() can be used to access the value of a private variable. I am unable to construct my own QName, with the same uri and localName, that is able to do the same thing, even in the debug player and in the same running SWF. There’s some magic in the one returned from getMemberNames().

The meaning of my original statement was that you can’t access private members in a production environment. I’m sorry for the confusion.

By: James Bond

James Bond — Thu, 22 Jul 2010 16:31:44 +0000

Josh, I think the statement that was made was that it was absolutely impossible to access private member variables outside of their defining class. I have provided a counter example showing it is doable; obviously there must be some limitations to it for helping to ensure the integrity of the application once its deployed. I have also described a means by which it can be accomplished. Did you try using my method to access the member variables outside at all?

By: Josh Tynjala

Josh Tynjala — Sat, 17 Jul 2010 18:01:19 +0000

James, flash.sampler doesn’t really count because it only works in the debug player. For the record, I was able to pass a private namespace object outside a class, but it only worked inside the class. I think I got a runtime error when I tried using it outside.

By: James Bond

James Bond — Sat, 17 Jul 2010 17:46:17 +0000

Josh’s last post is not strictly true (that you cannot access private member variables outside of the defining class). If you are able to obtain the right Namespace object, you can create a QName, and subscript the object via that to access any arbitrary property. The key issue is obtaining the actual Namespace object for a given class, which may not be possible in direct literal code. However….

One trick you can use is to use the getMemberNames() top level function in the flash.sampler package to retrieve an object that can be used to iterate over all of the member variable names (private or not) in a given object [you must be in the debug player for this to work, and there are other conditions as well]. Iterating over the returned object with a “for each” loop yields a series of QName objects that can be used via the subscript notation to access the value of the corresponding property, and this includes private member variables.

By: Josh Tynjala

Josh Tynjala — Thu, 10 Dec 2009 09:43:25 +0000

Yes, you’re right, karfau. public/protected/private/internal are all namespaces. I think your code should look like this:

object.private::_privateObjectProperty

Parentheses are used for E4X filtering, so they’re in no way usable here.

However, that won’t work. I’ve spent a lot of time trying to hack namespaces to see just what I can get away with. It’s not possible to access a private member outside it’s class. The private namespace is specifically defined with a different value in each class (on the global object, which is also a different object for each class file). So class Apple’s private is not the same as class Orange’s private.

In fact, it appears that the virtual machine has some extra protection. With the right function calls, you can trace the string representation of a particular class’ private namespace. However, if you try to define it in another class, it still won’t let you access something that’s private. Likewise, if you assign the private namespace to a variable and return it in a function call from the owning class to another class, it’s still useless for accessing the private members. This may be AS3 traits in action, or the separation of global objects in classes, or maybe defined by the language itself. Regardless, I’ve spent hours trying to hack private just because it sounded like a fun blog post. That sort of exploration actually led to the package/namespace relationship I revealed here.

By: karfau

karfau — Thu, 10 Dec 2009 09:19:12 +0000

this goes even further:
even public, protected and private are just namespaces:
usage from outside of the class would look like this:
var myref:* = object.(private::_privateObjectProperty);
wich compiles fine but (fortunately) throws a Type-Error when running:
TypeError: Error #1123: Filter-Operator not supported for type [type of object].

hopefully there is no way to get around this limitation (espacially for private and protected). I saw code-examples that changed properties of Flex-Components this way where those properties lay in the mx_internal-namespace.

karfau

By: Samuel Asher Rivello

Samuel Asher Rivello — Mon, 01 Jun 2009 08:47:00 +0000

Great post. I love the idea of assisting developers so they only seeing the methods via intellisense (of Flex Builder) for methods they need to see. I created a new demo to show that off. http://www.blog.rivello.org/?p=422

By: Almog Kurtser

Almog Kurtser — Sat, 16 May 2009 14:16:54 +0000

Great discovery, used this in my answer to a stackoverflow question.

By: Ian

Ian — Thu, 14 May 2009 17:26:34 +0000

How funny! I just made the same discovery about the change from “.” to “::” yesterday.

Unlike you, I was just distressed. It took me an hour to sort out why my app wasn’t working.