[chuck-users] Static bug
ge at ccrma.Stanford.EDU
Wed Nov 25 03:05:46 EST 2009
This is indeed actually a bug, not a feature! Static variables are not
initialized correctly (and currently need to be explicited initialized
outside the class definition). We hope to address this in the near
All the best,
On Wed, 25 Nov 2009, Stefan Blixt wrote:
> Ah, sorry Hans, I didn't read your original example properly. Static members
> should be initialized the first time the class is referenced, at the latest.
> 2009/11/25 Kassen <signal.automatique at gmail.com>
> > That is my worry, too: lack of intuition. It invites errors.
> I agree. The current behaviour is predictable, it could be called
> "expected" but I don't feel it's intuitive and I agree that it invites
> error. It's currently on the bugs page though it should probably be on
> a "open for debate and better suggestions" page instead.
> I feel there is a issue here but I'm not sure I have a alternative. We
> could have -for example- have a parser warning at this. We could also
> simply have attempts at setting values at definitions of static
> members result in a error or we could make a exception and set the
> value at defining the class itself. Then again; what if it's not a int
> being set as in;
> 3 => static int foo;
> but a function-call returning a int? This;
> my_fun() => static int bar;
> might have side effects that could be quit far-ranging.
> I think that if it were my call I'd suggest leaving this be and
> dealing with it once we get 'round to constructors. It does have uses
> as it is; for one thing it can tell us whether this static member is a
> member of a class that has a instance at all, in convenient -if
> hackish- shorthand. Classes and instantiation have far worse issues
> than this, though indeed this particular behaviour could stand
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> Release me, insect, or I will destroy the Cosmos!
More information about the chuck-users