<div>@Tom: nice idiom!</div><div><br></div>The first time I saw the static thing (in a discussion here or at <a href="http://electro-music.com">electro-music.com</a>), my immediate reaction was: &quot;why is that here? Isn&#39;t static pretty useless in a ChucK class where you can just write a function outside of it?&quot; In that other language I like to talk about (starts with a &#39;J&#39;), a major reason for having static members and methods is the fact that you aren&#39;t allowed to create functions anywhere else except somewhere inside a class definition. But the world couldn&#39;t be made completely oobject oriented, so they introduced &quot;static&quot; to indicate code that lives outside the instances of the classes.<div>
<br></div><div>In ChucK you principally don&#39;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.</div>
<div><br></div><div>I&#39;m feeling bold today, so I&#39;d like to suggest to leave static parts of classes in the state it is today for backwards compatibility (deprecate - it really doesn&#39;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:</div>
<div><br></div><div>namespace cool {</div><div>  namespace stuff {</div><div>     7 =&gt; int coolClassConstant;</div><div>     class CoolClass {</div><div>        coolClassConstant =&gt; int coolthing;</div><div>        // etc...</div>
<div>     }</div><div>  }</div><div>}</div><div><br></div><div>// Three days later, in another ChucK file:</div><div>cool.stuff.CoolClass coolInstance;<br></div><div><br></div><div>Again: classes really ought to only contain stuff that&#39;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&#39;s not needed, (i.e. AdvancedCalculalator.calculate() inside the AdvancedCalculator class) .</div>
<div><br></div><div>/Stefan</div><div><br><div class="gmail_quote">On Thu, Nov 26, 2009 at 9:06 PM, Hans Aberg <span dir="ltr">&lt;<a href="mailto:haberg@math.su.se">haberg@math.su.se</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 26 Nov 2009, at 19:29, Tom Lieber wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So the idiom I follow is the initialize-after one that&#39;s been<br>
mentioned a few times:<br>
<br>
class War {<br>
 // declarations and instance initialization<br>
 static int foo;<br>
 static Gain @ mix;<br>
 static int bar;<br>
}<br>
<br>
// static initialization<br>
3 =&gt; War.bar;<br>
new Gain @=&gt; War.mix;<br>
<br>
It&#39;s not intuitive to write (until you&#39;re used to it), but it is to<br>
read. It&#39;s clear that the static initialization happens once, right<br>
after class declaration. The static variables can be considered<br>
initialized anywhere in the class. There&#39;s no floating &quot;War war;&quot; to<br>
get things rolling. If it&#39;s a public class, it&#39;s likely that this is<br>
all that&#39;s in the file.<br>
</blockquote>
<br></div>
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).<br>
<br>
As &quot;static&quot; does not have any other use outside classes, it seems me it can be treated just like introducing namespaces. So<br>
  class A {<br>
    3 =&gt; static int k;<br>
    fun static void f() {}<br>
    ... // Non-static stuff.<br>
  }<br>
would be equivalent to<br>
  namespace A {<br>
    3 =&gt; static int k;<br>
    fun static void f() {}<br>
  }<br>
<br>
  class A {<br>
    ... // non-static stuff<br>
  }<br>
<br>
One might introduce &quot;static&quot; as an {...} environment. Then the above might be written<br>
  class A {<br>
    static {<br>
      3 =&gt; int k;<br>
      fun void f() {}<br>
    }<br>
    ... // Non-static stuff.<br>
  }<br>
<br>
This might be a handy way to write static functions: if they are global, just move them into the class within a &quot;static {...}&quot; construct. And one might put in other global initialization code there, if one so likes.<br>
<font color="#888888">
<br>
  Hans</font><div><div></div><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
chuck-users mailing list<br>
<a href="mailto:chuck-users@lists.cs.princeton.edu" target="_blank">chuck-users@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-users" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Release me, insect, or I will destroy the Cosmos!<br>
</div>