Hi Kas: My fault for not pointing this out: one contained a reference to the other, not an instance. But even when both are references, ChucK still won't compile it. 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. Here's how I would express it (and lose): ================= [file: controller.ck] public class Controller { Engine @ engine; } [file: engine.ck] public class Engine { Controller @ controller; } % chuck controller.ck engine.ck [controller.ck]:line(2): undefined type 'Engine' ================= There must be some ChucK-ish idiom that I don't yet understand. - Rob On 13 Mar 2009, at 04:35, Kassen wrote:

Rob;

How does one compile cross-referenced classes?

Wait. Let me get this straight; you want a "scratch" to contain a "sniff" and a "sniff" should in turn contain a "scratch"? Yet that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and that "scratch" will contain another "sniff" and that "sniff" will contain a "scratch" and this will go on forever? Is that correct?

I think I'm going to have to agree with Tom here; you shouldn't do that.

Let's take a step back and look at what you are actually trying to accomplish, practically speaking, and see how we could go about that.

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Here we go; this works; the controller sends commands to the engine, the engine executes those but depends on the state of the controller for the final result. there is a issue where the classes need to be defined above the actual code. This is no real issue when working with multiple files and public classes but I still think it's against the language specs. This is probably another example of the bug that creates a need for classes that extend Event to be defined above the spot where we use broadcast or signal on them. Cheers, Kas. ==========example code below================ //we need to define the classes at the top or the casting will fail //I considder this to be a bug. class Foo { fun void control( int message) { } fun int querry () { return false; } } class Engine extends Foo { Foo controller; fun void control ( int message) { <<>>; } } class Controller extends Foo { Foo engine; int state; spork ~ work(); fun int querry() { return state; } fun void work() { while(1) { second => now; !state => state; engine.control( maybe ); } } } Controller boss; Engine motor; boss $ Foo @=> motor.controller; motor $ Foo @=> boss.engine; hour => now;

Rob; How absolute the knave is! We must speak by the card, or equivocation will

undo us!

I don't know, equivocation may well still undo us...

Thanks.

That's ok, I had good fun. Cleaner would likely be defining a class "proto_engine" and one "proto_controller", adding those, then extending both, this avoids needing a rather clumsy class that has some members of both Engine and Conttroller; that's bound to lead to confusion later on. It turns out you are right, BTW and that you can create references to classes without instantiating them, from there on you can only use static members of those; class Foo { static int bar; fun static void printA() {<<<"bang">>>;} fun void printB() {<<<"bang">>>;} } Foo @ baz; <<>>; baz.printA(); //this creates a nullpointer baz.printB(); Could get useful, I suppose, but I don't anticipate I'll use this a lot. Kas.