It's already worse that this, the actual Torque implementation is in a Singleton which is handed out to TorqueComponent. So we can have more than just one TorqueComponent, however they all refer to the same TorqueSingleton implementation through facade accessors. No, I'm not proud on this, but we want to keep the static facade for at least one more release because Torque standalone users are using this.
You aren't going to be flogged for trying to maintain backwards compatibility with poor design here. I think we have all inherited a system we *really* did not like the design of and had to support it. Many times the concepts are good, but the implementation needs help. ;P
The fact that you are aware of the issues involved with the way things are is a good thing.
The problem is, that some parts of user code (Turbine in this case), simply does Torque.<do something> without knowing that Torque has been loaded by an Avalon Container.
You can refactor the Torque.<do something> methods to internally call the same factory method to ensure the instance is the same. That way you can update things internally without breaking client code. It's one way of partially correcting the underlying problem.
You will have to add the proper try/catch block, but it will ensure you get the TorqueComponent even with delayed initialization.
The idea is good and actually we do a similar thing in the Torque facade and the TorqueComponent but we must support Users which use Torque without Avalon, so we can't go this way (yet).
By that, do you mean that you can't have a dependency on Avalon, or that you can't do the factory method?
Just how many access points for getting the Torque reference are there?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
