[chuck-users] chuck miscellaneous sharing data

[Graham Coleman]

> Theoretically we have global variables and functions.  You can declare
> a public class with static members and those should be accessible by
> all subsequent code.  For example:
>
> public class The
> {
>      static int number;
>
>      // a bug forces one to declare static objects as references
>      static Event @ event;
> }

Static variables in public classes work for sharing data.
But perhaps there is a more elegant way to do this.

If you want to share just a bit of data between future shreds, one must
use two of lines syntax minimally, but it's big on words and
punctuation and short on meaning:

public class Foo { static int bar; }
4 => Foo.bar;

If I define a class in a shred file and make changes, the VM doesn't allow
you to redefine the class (so you must remove it from your buffer). This
is a temporary practical problem.

Also, it semantically implies there is some class of objects called Foo,
and bar is a piece of data that relates to all of them. We aren't really
sharing data between instances of Foo, we're sharing data among shreds.

We are only using classes for this because it allows us to hijack a global
namespace in the VM (the namespace of classes) for sharing data. We could
also do this by having a machine-wide dictionary:

machine.set( "beatEvent", new Event ); //this has typing issues

or perhaps like this:

3 => glob int bar; //this has a bad reputation

Globals have a bad reputation for cluttering programs. But in this case
using class data isn't much better, and requires more meaningless syntax.

Of course, static class data does have some things going for it. Overall,
the syntax of ChucK is very minimal, and it conforms to the expectation of
standard languages (mostly C++ and Java). This makes it easier to learn
and understand, and it might make it more timeless. For a java programmer,
storing global data in class (static) variables provides minimal surprise.

Arguably, live-coding environments are subject more pressure than systems
and applications languages to be clear and to be terse.

best,

Graham