2009/3/13 Robert Poor
<rdpoor@gmail.com>
Hi Kas:
My fault for not pointing this out: one contained a reference to the other, not an instance.
You are saying it merely contains a reference to the class itself, names that and doesn't actually instantiate it? This would be useful for public classes with static data? I didn't know you could do that but I suppose it could make sense.
But even when both are references, ChucK still won't compile it.
I think it's quite clear why not; both files depend on the other file to be useful; basically both need to be run first yet in practice ChucK can only do one thing at a time. I fear this simply won't fly. Either the chicken or the egg will need to come first.
Imagine you had a "controller" object that controls an "engine" object, but the engine needs a reference back to the controller, e.g. to query its state. This is a standard programming pattern.
Ah, ok. Erm.... maybe define a class "Foo" that has both the controling and querying functions (at least functions of that type and name) and extend it twice, once for the engine and once for the controller? That way you could run the file containing the Foo class and refer to that type in the engine and controller code, you'd then instantiate the engine and controller and asign the engine to the Foo in the controller and the controller to the Foo in the engine from a fourth file. That way the classes can be defined in any order as long as Foo goes first and we'd instantiate and asign after that. I think that might work...
Not especially pleasant, I admit, and you better not need arrays or there will be "Clemow's bane" type trouble.