Yes, by global I meant that it is defined outside the function in the class bracket itself.
It was declared as is (no access keyword), which I believe means it is internal or private.
So please read:
private var _proxy:MyProxy = new MyProxy();
The Mediator is instantiated once in the application and no other part of the framework accesses this proxy instance.
So allow me to play the devil's advocate and preemptively argue with you (because I will no doubt have this argument myself, and I don't want to start it until I am sure I will win).
1) So that more than one actor can retrieve it.
No other actor will need this. The data this proxy retrieves is for this Mediator. It's in the docs.
2) So that you can ensure there's only one instance of it in use within the app (if need be) without having to implement it as a Singleton.
Ok, we used to make these Singletons until you told us to stop doing it. So shall we go back to making our Proxies be Singletons?
3) For the life cycle benefits of registration with the Model. When the Proxy is registered, it's onRegister method is called. This gives you a common place to set up your services and add listeners. When the Proxy is removed from the Model, onRemove is called, giving you the opportunity to remove those listeners and do any other teardown to ensure its availability for garbage collection.
This is very esoteric. But for this particular case, the actual listeners for the URLLoader are inside the Proxy itself so I don't see any problem. We have to use the same due diligence here as we do when registering listeners inside of view components. Those don't have any onRemove(). Furthermore, when have we ever unregistered a Proxy? Why would we ever unregister any Proxy? Anyway, esoteric as it is, this argument might be persuasive under other circumstances, but why all the trouble for this little URLLoader Proxy?
4) Because if another actor needs this Proxy, they'll have to instantiate it as well (thus duplicating resources and not having access to the other instance's data), or ask this mediator for it, which is way outside the scope of the Mediator's responsibilities.
Again, no other actor will ever need this Proxy. It's in the documentation. The requirements are not going to change. In the unlikely event that they do, we will refactor the code then. Refactor is normal. You have to refactor at least a little every time a requirement changes. And when we refactor, then let's talk about whether we should use Singleton pattern again. For now, if it ain't broke, don't fix it.
Ok, me again. Some of these "rebuttals" I admit are pushing the limits of absurdity. But well, all I can do is point to the original code as evidence of the thinking commonplace here. Of course, at the end of the day, if people really insist that using the Singleton pattern as an alternative to registering proxies is the way to go, then I have to ask why we are bothering with the pretense of PureMVC in the first place. But then that puts me in the position of advocating we either stop using the framework in favor of not having one at all, or using PureMVC standards because that's just the way you do it in PureMVC. I've won with the latter argument in the past by virtue of just being frothy about it ("Well, if you feel that strongly about it ok..."). But I would rather be able to persuade folks of the merits of coding correctly.
Perhaps the problem here is not about the merits of PureMVC standards, but about having standards and following them consistently in the first place, even when the standard results in some "unnecessary" boilerplate at times (eg registering a Proxy that is never used by any other actor, never requires clean-up, etc.). I'm going to stop here before I begin venting and focus on why I posted the original message, which is that I am looking for persuasive arguments to make for following the PureMVC standards even when doing so seems unnecessary for the above reasons.
Thanks for bearing with me. I know this isn't the first time...