I have some problems with the "static" thinking in C#... It seems it is not legal to access a static method or member variable through an instance.
public FSM fsm;
instance -> fsm.transition();
static -> FSM.SomeMethod();
Question for C# Unity Users - How does one know for example in the Unity Engine which methods or members are static and those that are instantiated?
Console is actually a public sealed class, but Console.ReadLine() is a static method. C# doesn't strictly support singleton classes in the sense that there's a keyword (like Java's
It's interesting that you should point out the ambiguity between instance access and static access, I'd never realized that, as in your example with A.B(). You see, you're never really in doubt if you use an editor with proper syntax highlighting. Here's an example with a bit of code I zoomed in on, in Visual Studio 2010:
Notice the light blue color? Everything colored light blue is statically accessed. If it's black, it's variable access. I.e.
The docs list a var/function as a class function if it is a static, which seems like pretty standard C# convention.
C# really is confusing that way, it's not a Unity thing. In C++, regular functions are probably in a namespace, and you use
Whereas C# (not just Unity) encourages you to group regular functions in "fake" classes, full of only statics and no member vars, which will never be instantiated. You can never tell in A.B() if A is a variable or a scope. I always assumed it was a design issue: I'm not sure if Console if a singleton or a class, but I use
answered May 24 '11 at 06:03 AM
I normally rely on naming conventions, i.e. fsm is a field, whereas Fsm is a class. What does cause problems is when you have a public property of, for example, a Rectangle that is called Rectangle. In this case, you would have to use either highlighting or looking at statically available functions. VS does make this really clear, IntelliSense is much better than normal rules.
answered May 24 '11 at 08:00 PM