views:

125

answers:

1

As the title suggests, why are the applyResult and applyFault methods of AsyncToken marked mx_internal?

There have been a few times that I would have liked to use AsyncToken in my code, but I've ended up re-writing it because I don't want to force clients to use namespace mx_internal.

+1  A: 

Well, as stated somewhere in the livedocs (I think) mx_internal is used to mark things in the framework that might change over time (apparently they thought C# and Java are doing it wrong with the deprecated stuff). As to the exact reason why those particular methods are marked mx_internal only the developer that marked them knows. They probably met one day to discuss it and it went something like: "Hey. What access do we want for those methods" "I don't know, do we want them to be overridable?" "Not sure" "Ok, let's make them mx_internal then". There were many cases where methods that should have been marked protected were marked mx_internal (or private which is even worse in some cases) instead, and it's one of the most annoying things in the flex framework.

Also, you're using the mx_internal namespace whether you want it or not, because most of the components in the framework import it, so if you use the flex framework components, your build already includes it.

bug-a-lot
Thanks for the reply – I'm glad to know I'm not alone in feeling that Flex's access modifiers are insane. Also, it's not that I don't want to load the `mx_internal` namespace… I just don't want to force end-users of my library to `import mx.core.mx_internal; use namespace mx_internal` every time they want to send my code an `AsyncToken` (I've gotten around this by re-writing `AsyncToken` calling it `DeferredResult`).
David Wolever