A different use for custom namespaces (1/2)
by Ruben
Note that to keep the focus on the abstract/theoretical part of the subject I seperated the content over two seperate posts. The first (this one) explains the idea while the second shows a possbible use-case and some example-code.
When namespaces were first introduced in Actionscript 3 I thought it was all pretty cool, but still I sort of had a difficult time thinking of actual use-cases.
What I initially would have liked to use custom namespaces for was to restrict access to certain properties/methods, to only be accessible for certain classes, in the way that private and protected enable you to -- unfortunately there is no simple way of defining who can import your namespace, consequently rendering namespaces somewhat useless for this particular use-case.
Then some time ago it struck me that rather than defining new members with a custom namespace, that you could of course also enhance an existing method instead (I admit this might seem like a no-brainer, but it took me a while to bump into).
Let's say you have a subclass that for regular (outside) usage needs to override a method in the superclass, but itself still needs to use the original (super-) method. You would probably just override the method in the subclass and use super.method() wherever you needed to use the original functionality.
Now let's say that you need to make a subclass of your subclass, which would also require access to the original functionality in said method. All of a sudden super.method() will not work for you anymore.
Here's where namespaces start coming in handy, while still simply overriding the method in the first subclass, you also implement a function with the same name but with your own namespace (for example "original"). Then whenever you need to call the original implementation you can call original::method(), regardless of how deep down in the inheritance-chain you are.
This is only one use-case, you could for instance also use this concept to work around the nasty ambiguous-reference bug you get (or used to get) when declaring a getter and a setter with different (native) namespaces.
To keep the focus on the above described concept I put the example-code in a seperate post, feel free to read on though.
Comments (also 2 trackbacks, click to show)
Trackbacks:
While this is very nifty, fail to see why this could simply be done by creating a method with a different name and then calling the original from there?
Secondly the need for this seems to me to indicate a case where inheritance really shouldn’t be used. If you need to circumvent the implementation of your super-class there is most likely something wrong with the design in my opinion.
Thanks, of course this could just as easily be done with a method with a different name, but then again why would you use another name for a method that is just a different ‘version’ of the same functionality, and what would you call the method? I think namespaces are much more of a clean/elegant solution to marking different implementations of a method then getting into naming like “original_myMethod()” and such.
Regarding your second point, I think you might be overgeneralizing — while in some cases the need for such a solution to a problem may be an indicator of a glitch in your design, the idea described in this post is way too abstract to state that for every situation it is applied in there is a problem with the design.
On top of that as a developer you don’t always have control over your superclass, it may be from a third-party precompiled library or a class you can’t change the structure of because it’ll break other existent functionality.
you can use namespaces to restrict access
see: http://livedocs.adobe.com/specs/actionscript/3/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=as3_specification114.html
other use cases where namespace can be useful are unit tests, where for ex you need to set some internal value that you can not access directly in the class, but you want to setup to test a particular thing
Hey Zwetan,
Sure you can juggle around a little with references to namespaces to try and restrict access, though I have yet to see a waterproof method — for example in the sample-code in the livedocs, all you have to do is find an instance of a valid class and pass its reference to
beMyFriend(), after that nothing stops you from callingmakeMyDay()from whatever class you please..What I was trying to say in the start of my post was that there is no explicit (and foolproof) way to configure namespaces to only be applicable/accessible to certain classes.
hey RUBEN,
wow!!!!! i like it.
thanks