Why does unity not initialize public properties in AddComponent?

This is a minor thing, but still managed to confuse me for a good hour.

I noticed that if I create a component which has a public property like List<int>, on Awake Unity seems to initialize the property for me. Handy I guess since it prevents nulls.

However, if I create the script through "AddComponent", I noticed the list won't be initialized and left as null.

Is there a reason behind the scenes why Unity initializes one and not the other?

Cheers.

 

So the Inspector can work properly.

 

But don't the Start and Awake functions run when the component gets added? Shouldn't that be initializing the properties?

 

Assuming you do it in Awake, yes. If you do both then you'll wipe your Inspector assignments when entering play mode.

 

I wonder then - what's the difference between the inspector property when it has a component added through the editor (drag and drop) and a component added through AddComponent? If it's for the inspector to work, shouldn't it act the same for both? At the end of the day its the same script on the same object with the same public property.

 

This is a subtle but deep distinction. When a component shows up in the inspector, Unity has done an internal initialization. Unity serialized the values that are exposed on that object. Part of the Unity Inspector treatment of an object is to create default values for lists and other collections that Unity knows how to serialize. This treatment only occurs in the editor.

When you use AddComponent at runtime, the editor doesn't have a chance to initalize the object in the same way. So components added with AddComponent aren't deserialized from backing data, which means that no default collections are created.

If you want the convenience of knowing that your class's public Lists aren't null, you can use a field initializer to give it a default (empty) list.

 

That's cool! I always wonder how you guys figure this stuff out, ha.

Thanks Kru, great info.