[chuck-users] Class Libraries, File Naming Conventions, and 'machine.add(...)'

Ge Wang gewang at CS.Princeton.EDU
Thu Mar 30 01:10:35 EST 2006


Greetings!

> awesome!  glad its working out for you.  Uhhh, its fine by me if 
> miniAudicle questions go either here or to the audicle list, but if 
> anyone thinks thats too off-topic (Ge...?) maybe i could set up a 
> separate list for those questions.

The miniAudicle is a (great) way to chuck, and most relevant to this 
list, I reckon um hmm...

>> (2) Am I using 'machine.add(...)' for its intended purpose (in loading
>> classes)? Might there be a good reason to add another
>> 'machine.load(...)' that does the same thing as 'add', except it does
>> not spork a new shread for each call? This 'load' function could also
>> be made to keep track of what files have been loaded, and any time
>> there is a file that gets loaded more than once, any subsequent loads
>> could just be ignored? (This might also change the miniAudicle
>> interfact to include a button to load, in addition to the other
>> buttons.) Would this function be best named 'load'/'include'/'import'?
>> Which one?
>
> Seems reasonable to me to use machine.add() for loading classes.
>
> while machine.add() does spork a new shred, programs that only define 
> a new public class will exit immediately anyways.  Also, chuck already 
> rejects files that try to redefine public classes, with a compilation 
> error.  So functionally machine.add() operates very similarly to such 
> a load routine, even though they might be conceptually different 
> operations.  Although there are certainly cases where extended class 
> library loading functionality would be desirable.

Yeah, machine.add() is way to go for now.  It's different from a static 
'import' or 'include' in that it happens at runtime.  We are however 
working on the include system, which will hopefully make loading much 
simpler/safer and automatic in places.

>> (3) Any thoughts on why the classes do not load when I have subsequent
>> code in my program (after the 'machine.add')?
>
> Thats strange... I have not come across this behavior in similar 
> programs.  Are you getting any unusual messages on the Console 
> Monitor?

What kind of code do you have after the machine.add(...)?  If the code 
tries to use the classes in the files you are adding, that won't work 
in the same file because machine.add() is a runtime construct.  For 
example:

foo.ck
---
public class Foo
{ /* stuff */ }
---

bar.ck
---
machine.add( "foo.ck" );
Foo foo;  // this won't pass the type checker
---

running bar.ck first (the intended usage) would result in a type 
checker error 'unknown class Foo', since foo.ck won't be added until 
runtime and so 'Foo' is unknown when bar.ck is compiled.  for now, you 
would have to separate the machine.add(...) into a different file from 
such code.  this part of the language really needs work, and we have 
been actually working on it.  hopefully we will have some working 
prototypes in a few releases from now.

Wow, that was a big paragraphical mess I just typed, and I am not even 
sure I answered the right question...  Is this the problem you were 
referring too, Mike?

Doh,
Ge!



More information about the chuck-users mailing list