Forum ‹ C# ‹ Static fields are disallowed

[sidwoo]

Is there a special reason why "Static fields are disallowed" ?


Edit:
i removed the static stuff from my script but i still get this error:
MyGame.Properties.Settings.defaultInstance ist static -- Static fields are disallowed

Could that have happened because i changed project settings?!

EDIT2:
Ok, now i found the settings and deleted them ...

[Oliver]

Hey,

Static fields are disallowed, because you'd probably try to use them to have share game-wide data, but since we run instances of your rooms across many different servers, each room would see a different value in the static variables depending on which server they are running on.

To avoid such confusion, we simply decided to disallow static properties.

Best,
Oliver

[sidwoo]

ok thankx, took const now

[jasonMcIntosh]

What about static constants? Those are really, really useful and help improve code integrity. They would not change across servers, obviously, since they are constants.

EDIT: Just wanted to clarify my use case. The sort of thing I mean is like using MOVE_MESSAGE_ID (a string constant) in place of typing "move" every time. The latter is prone to subtle bugs from typos. The former also allows you to change the value in just one place instead of doing an error-prone search/replace. I'm sure you already knew what I meant.

[Benjaminsen]

What about static constants? Those are really, really useful and help improve code integrity. They would not change across servers, obviously, since they are constants.

EDIT: Just wanted to clarify my use case. The sort of thing I mean is like using MOVE_MESSAGE_ID (a string constant) in place of typing "move" every time. The latter is prone to subtle bugs from typos. The former also allows you to change the value in just one place instead of doing an error-prone search/replace. I'm sure you already knew what I meant.

We choose a route where we decided to always disallow static fields. There is however nothing preventing you from declaring a variable and using that all over. If you insist that the value must be read only you can use:

Code: Select all

string MOVE_MESSAGE { get { return "move"; } }


[jasonMcIntosh]

Fair enough. A small price to pay for everything else we get in exchange.

[Henrik]

Another way of doing it is like this:

Code: Select all

public readonly string MOVE_MESSAGE = "move";

[jasonMcIntosh]

I'm actually using static functions to return the values, which seems to work ok so far.

I created a wrapper class for Message so that I can define message fields more explicitly (ie, moveMessage.positionX) rather than having to remember array indexes. I want to avoid bugs where I've used the wrong array index or later change message fields/ordering.

Code: Select all

class HelloMessage : GameMessage // GameMessage contains an instance of Message
{
    public static string ID() { return "1"; }

    public HelloMessage() : base( Message.Create( ID() ) )
    {
    }

    public override string id { get { return ID(); } }
}


That message doesn't have any payload, so there are no Message access wrapper methods, but I hope this will reduce bugs for me in the long run.

Anyway, you can see here that I can access the message id from the instance or statically. Now I only need to define the message id once, in this file, and I won't have multiple definitions floating around that will cause pain later when I forget to change one.

Thanks for the ideas!

[jasonMcIntosh]

Just wanted to mention that

Code: Select all

public MyClass
{
    public const int MY_VALUE = 777;
}


works as I desired since const properties are implicitly static when defined in the class declaration. Yay!!

Henrik, your alternative proposal (using readonly) seems really close to this, and I don't yet understand what the difference is, but I'm happy to have static access to ids and other immutable data.

So, there's no more whining from me about this issue.