Stefan;

I forget - what separates static functions from other kinds of functions?

They can only reference other static members and variables. That may sound like a downside but it also means they can be called without a object instance. This becomes useful in the case of functors (see the recent forum discussion), for example. Right now if we want overloading we also must create object instances of all extended classes. Right now this isn't much of a issue aside from me finding those extra lines ugly because they don't actually do anything useful (well, aside from making it work at all), but I anticipate problems if/when the much desired include functionality would get here. I would like to be able to extend classes without needing a object instance when instances don't actually do anything meaningful in the case that I might have. To me this seems like a solid case but it wouldn't be the first time that the nice people with ".cs." in their email address would expose me for the hack that I am ;-). The error message implies that the matter has been given some thought but I don't get what the reasoning is. Kas.

Getting OT...

but maybe it's useful for the include file trick.

Wait, is there an include file trick? I thought we just had Machine.add(), which requires paths relative to ChucK's run spot. Also, wouldn't "#include ..." not work in the same way as C, since there can only be one public class per file? I guess it would sort of work, but you could only have local classes for the current and sporked shreds. I would comment on the original question, but I didn't know what static functions were until Kas explained them. So, thanks Kas, sounds cool. Andrew 2009/9/8 Stefan Blixt :

ChucK often seems inspired by Java, and I suspect that's the case here.  Static functions and variables in Java works just like you describe for ChucK - the class is here basically just a kind of namespace that wraps the methods and variables, since they live outside the object oriented world of instances. In Java, static items are always specified using that namespace, e.g.: class A {  static int v; } int b = A.v; Inside classes, you can omit the class name, which is implied: class A {   static int v;   int f() {     int b = v;   } } You can reuse a static name in a subclass. However, this is not the same as overloading, since you always specify the class containing the static member, and if you don't specify it it is implied that it is in the same class:

public class A {

static int f() {

return 1;

}

static int test() {

return f();

}

}

public class B extends A {

static int f() {

return 2;

}

static int test() {

return f();

}

}

A.test() will return 1 and B.test() will return 2. This code would work exactly the same if we removed the extends - static code bypasses the object stuff.

Maybe the ChucK people thought this behaviour might make for hard-to-read code, and simply banned reuse of static method names? There is no other reason I can see why this isn't allowed. I'm personally a bit confused abut the static concept in ChucK, since we can put stuff on "the ground" outside class space, but maybe it's useful for the include file trick.

/Stefan

On Tue, Sep 8, 2009 at 6:06 PM, Kassen wrote:

...

Stefan;

...

I forget - what separates static functions from other kinds of functions?

They can only reference other static members and variables. That may sound like a downside but it also means they can be called without a object instance.

This becomes useful in the case of functors (see the recent forum discussion), for example. Right now if we want overloading we also must create object instances of all extended classes. Right now this isn't much of a issue aside from me finding those extra lines ugly because they don't actually do anything useful (well, aside from making it work at all), but I anticipate problems if/when the much desired include functionality would get here.

I would like to be able to extend classes without needing a object instance when instances don't actually do anything meaningful in the case that I might have.

To me this seems like a solid case but it wouldn't be the first time that the nice people with ".cs." in their email address would expose me for the hack that I am ;-). The error message implies that the matter has been given some thought but I don't get what the reasoning is.

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

-- Release me, insect, or I will destroy the Cosmos!

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

Stefan;

I'm personally a bit confused abut the static concept in ChucK, since we can put stuff on "the ground" outside class space, but maybe it's useful for the include file trick.

the main use comes from static members in public classes, which are the one and only way to share data (and functions, and UGens....) across the whole VM. Kas.