@Tom: nice idiom!
The first time I saw the static thing (in a discussion here or at electro-music.com), my immediate reaction was: "why is that here? Isn't static pretty useless in a ChucK class where you can just write a function outside of it?" In that other language I like to talk about (starts with a 'J'), a major reason for having static members and methods is the fact that you aren't allowed to create functions anywhere else except somewhere inside a class definition. But the world couldn't be made completely oobject oriented, so they introduced "static" to indicate code that lives outside the instances of the classes.
In ChucK you principally don't need this, since you can put code anywhere. The one thing (for me) that makes the static modifier necessary is that you want to reference code that is in another chuck file (which I guess is what people mostly use this for). Another minor benefit is namespace encapsulation.
I'm feeling bold today, so I'd like to suggest to leave static parts of classes in the state it is today for backwards compatibility (deprecate - it really doesn't make nice bedfellows with constructor code at the top of the class definition as shown in this discussion), fix referencing between chuck files, and introduce a new keyword to allow folks to build namespace hierarchies:
namespace cool {
namespace stuff {
7 => int coolClassConstant;
class CoolClass {
coolClassConstant => int coolthing;
// etc...
}
}
}
// Three days later, in another ChucK file:
cool.stuff.CoolClass coolInstance;
Again: classes really ought to only contain stuff that's actually going to be used in objects. Static kind of works in Java, but even there it causes confusion - there are even code standards where they dictate that you always qualify from which class a static function is used even if it's not needed, (i.e. AdvancedCalculalator.calculate() inside the AdvancedCalculator class) .
/Stefan
On Thu, Nov 26, 2009 at 9:06 PM, Hans Aberg
<haberg@math.su.se> wrote:
On 26 Nov 2009, at 19:29, Tom Lieber wrote:
So the idiom I follow is the initialize-after one that's been
mentioned a few times:
class War {
// declarations and instance initialization
static int foo;
static Gain @ mix;
static int bar;
}
// static initialization
3 => War.bar;
new Gain @=> War.mix;
It's not intuitive to write (until you're used to it), but it is to
read. It's clear that the static initialization happens once, right
after class declaration. The static variables can be considered
initialized anywhere in the class. There's no floating "War war;" to
get things rolling. If it's a public class, it's likely that this is
all that's in the file.
As "static" does not have any other use outside classes, it seems me it can be treated just like introducing namespaces. So
class A {
3 => static int k;
fun static void f() {}
... // Non-static stuff.
}
would be equivalent to
namespace A {
3 => static int k;
fun static void f() {}
}
class A {
... // non-static stuff
}
One might introduce "static" as an {...} environment. Then the above might be written
class A {
static {
3 => int k;
fun void f() {}
}
... // Non-static stuff.
}
This might be a handy way to write static functions: if they are global, just move them into the class within a "static {...}" construct. And one might put in other global initialization code there, if one so likes.
Hans
--
Release me, insect, or I will destroy the Cosmos!