When we expose a gameobject’s script’s properties and variables to an inspector we can change those values at design time and runtime because they are essentially variables.
However, the majority of these values in the inspector we realistically only change at design time. So it would make sense for the compiler to convert these none changing values to constants behind the scenes so they would perform faster than properties/fields. Potentially this would happen when a property/variable is marked with something like [RuntimeStatic] or something?
In a way, it’s similar to marking a gameobject as static.
I wonder if the Unity team would do something like this?
I don’t think it’s really possible to make them constants for a few reasons:
- they are instance values not static values. (They belong to a particular instance of the class, not the class as a whole)
- there’s nothing stopping you from changing the values at runtime, and even with some static analysis, Unity couldn’t detect reflective access.
Good points. Because constants are static by nature, they share the same value across class instances. So putting the same script on multiple objects would not work when the values you use in the inspector are different.
It seems logical in one way, but not in another. Due to class instances being instantiated at runtime, not compile-time this doesn’t make sense in a C# OO world but does in a more general notion of constant values that are defined BEFORE compilation.
1 Like