[chuck-users] Static bug

[Stefan Blixt]

@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 at 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.
>>
>
> I think chuck zero-initializes all stuff, so that would lead to a double
> initialization or introducing a new concept of non-initialized variable (as
> in C).
>
> 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
>
>
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>



-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20091126/d5be91f7/attachment.html>