When I do:
typeof(UnityEvent).GetMembers();
it returns nothing but methods visible from code, which are useless in serialization. Same for UnityEventBase.
But when I do:
JsonUtility.ToJson(myUnityEvent);
It returns JSON-formatted string with all those “hidden” members (like m_Calls), which I needed. Yes, now I can replace instanceIDs with something more persistent on serialization, then replace back on deserialization. But how does JsonUtility got these members? Is it some Unity internal black magic? Then why so serious? Are UnityEvents outdated?
In this case it’s not Unity related. You just have to learn how to use reflection if you really need it.
First of all you have to look at the actual implementation of the class(es). You will notice that most used classes are actually private classes. So you can’t use those classes directly and everything you want to do with them has to be done through reflection.
Next you should learn to read documentation. The .NET framework has a great documentation. As you can see the GetMembers method has two overloads, one without any parameters and one with BindingFlags. The BindingFlags enum is a bit mask enum. So you can combine several values with the bitwise or operator. By default you will only find public and instance members. However NonPublic members (private, internal, protected) as well as static members will not be found. You can combine all 4 values (Instance | Static | Public | NonPublic) to get literally all members of a type.
If it’s about serialization you usually only have to care about fields. Members could mean anything which includes fields, properties, (.NET)events, methods, nested types and some others. If you’re just interested in Fields, you should use GetFields instead.
Note that the UnityEvent class is purely implemented in .NET managed code. Therefore you can access all information through reflection. However the way it’s designed (and because most of the other required classes are private) it’s a mess to deal with UnityEvents manually through reflection. Though nothing is impossible.
It’s a different story for built-in types which are not implemented in managed code but actually in native C++ code in the engine core. Unity’s serialization system actually serializes the data on the native side. Therefore Unity has access to all fields that are actually implemented on the native side. For those classes Unity provides methods (actual methods or getter / setter) which are implemented in native code to read / write values of that class. The prime example is the Transform component. It doesn’t contain a single field in managed code. Everything is a property or method that is implemented on the native side. So in those cases you can only use the methods the class provides. Reflection allows you to call private or internal methods. Though if Unity doesn’t provide a method to access some internal data there’s no way to get it. In some cases Unity’s serialitation system might have access to data you don’t get otherwise.