[chuck-users] Static bug

[Stefan Blixt]

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.

/Stefan

2009/11/25 Kassen <signal.automatique at gmail.com>

> Hans;
>
>
> > 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 documentation.
>
> Yours,
> Kas.
>
> _______________________________________________
> 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/20091125/43fabe77/attachment.html>