Expose private methods to inspector?

Question

In Unity we can use the Attribute [SerializeField] to expose private fields to the Unity inspector like so:

[SerializeField]
private float speed;

Now I want to do the same for methods that I want to use in the inspector: for example OnClick callback methods for buttons. Using [SerializeField] does not work and from what I can tell there is no [SerializeMethod] or similar to expose this functionality. How can I expose private methods to the Unity inspector similar to how [SerializeField] exposes private variables?

To understand what I mean by "expose" I meant having it show up in the inspector like this:

The reason I want this functionality is because I just encountered a bug where I was calling a public method from a script that was just meant to be called as a callback to the OnClick method. Pretty much the same reasoning as wanting to use [SerializeField] to hide variables but expose them to the inspector.

Answer 1

You can't

Private methods can't be exposed to the editor. Your goal her is to have another script invoke the method, and the only way to do that (and in fact the only thing that even makes sense) is for that method to be public.

Technically speaking, you could invoke private methods via Reflection, but this is a performance nightmare and is not recommended. As such, the Unity Editor doesn't allow private methods to be the target for invocation in this manner.

Alternatively, you can allow buttons to invoke private methods by assining the Onclick behavior via code:

Button btn = someGO.GetComponent<Button>();
btn.onClick.addListener(delegate { myPrivateFunciton(); });

The scope that this code is running it has access to myPrivateFunciton and therefore has the executive authority to pass off a reference to another object (in this case, the button), similar to passing a private field reference to another class instance.

Answer 2

This topic seems to be very old, but since I stumbled upon the same issue and found this topic, here is my solution.

In nutshell, for every Unity component that exposes "Unity-only" methods you make two classes:

1. Main class. A well designed public class that follows all the best practices. It declares Unity specific methods (like callbacks for the controls) as protected. The external consumers of your code will see this class and will only be able to use what you've explicitly declared public. They will be able to inherit and access the protected methods, but it would also require them to replace the component. And given the difficulty of dealing with the serialized Unity fields, I'd say it's not feasible. So, we may safely assume nobody will be calling your protected methods.
2. Decorator class. A private protected sealed class that inherits from the main class and declares new public methods for what was declared as protected in the main class. The external consumers won't be able to see this class, but Unity will be able to see this class and invoke its callbacks!

The downside of this approach is that you cannot declare the main class sealed. But it's tolerable. Not that many people use it anyway.

Simple code sample:

// This class implements the logic.
public class MainClass : MonoBehaviour {
  protected void MyUnityCallback() {
    // External callers won't be able to use this method.
  }
}

// This class exposes methods to Unity.
sealed class MainClassDecorator : MainClass {
  public new void MyUnityCallback() {
    base.MyUnityCallback();
  }
}

HINT. Using "debug" mode in Unity inspector you can easily replace the main class by its decorator.

HINT2. To enable debug mode in the editor, right click on the inspector tab title.

Answer 3

You seem to have a misconception about how accessibility-levels work in C# (or programming in general). An element marked private cannot be accessed outside of the class it's declared in, by definition.

The reason you are able to expose fields is because the editor is not working with the actual run-time instance, but rather with a serialized copy that the editor will substitute with an instance when the time is right. Fields are serializable, and serialized types that have a Drawer show up in the inspector, so when you override Unity's default behavior using the [SerializeField], and the protected/internal/private field gets serialized, it will show up in the inspector. It's more of a consequence of how the system works, rather than actually "exposing a private field" as if it was a concrete action that could be taken.

Methods are not serializable. Methods aren't data; they are procedures. It makes no sense to serialize a definition of "how to do something". Definitions are the responsibility of the classes/assembly. --- This is also the reason why you can't deserialize data without access to the assemblies that define it. The compiler is not clairvoyant; it needs to know the format that the data is supposed to be in, in order to reassemble the data back into a concrete instance.

Since methods aren't serializable, the inspector can only know about them through reflection. And while there are ways to get references to non-public methods through reflection, it will not be something that Unity will provide out-of-the-box, because it's something that presents many problems:

• It breaks encapsulation.
• It breaks the strictness principle.
• It would lead to massive clutter.
  • The method-lists that Unity displays only show public methods; there are hundreds of non-public classes, and possibly thousands of non-public methods being omitted. The editor's reflection can't differentiate between the method you want to expose, and all other non-public stuff; it would have to show them all, and that would make the system unusable.