0

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.

David Wolever
  • 148,955
  • 89
  • 346
  • 502

2 Answers2

4

If you'd built this class you'd want to hide the functionality away from normal users, as you don't want them mistakenly invoking the methods, but the internal classes that create them need to invoked them, therefore marking them as mx_internal makes good sense.

Tink
  • 41
  • 2
  • It does make sense *if* the class is *not intended to be used* by "normal users". But, apart from the fact that the `apply` methods are `mx_internal`, there is no indication that this is the case. What happens if I want to write a method which which returns an `AsyncToken`? – David Wolever Dec 07 '12 at 20:45
1

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
  • 2,446
  • 1
  • 22
  • 27
  • 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 Oct 22 '09 at 13:54