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.
Hans;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.
> That is my worry, too: lack of intuition. It invites errors.
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 documentation.
Yours,
Kas.
_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users