How to access `GameObject` to which `MonoBehaviour` is added from C# `Attribute`

Question

Unity's RequireComponent inherits from System.Attribute. Somehow they made it that whenever component is added it has a reference to GameObject its being added to. So they can callAddComponent` to it.

I am trying to replicate that behaviour.

My theory is that because UnityEngine.RequireComponent has types stored inside class - they do it by reflection later. In method AddComponent<T> they get T class attributes from type and then try to cast them, get information from them, and apply to GameObject. If that is the case, then I doubt I will be able to do something with it, unless I have access to change AddComponent<T> somehow.

Is there another way around it?(that is no problem to do in code (just extension), but what about how it will work in inspector) Maybe apply different method to Unity`s default component addition.

EDIT

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public class RequireComponentAttribute : Attribute
{
    public RequireComponentAttribute(Type type, int quantity)
    {
        if (quantity < 0)
            throw new ArgumentOutOfRangeException("Required components quantity cannot be negative");
    }

#if UNITY_EDITOR
#endif
}

Answer 1

C# attributes do not work the way you'd need them to work to do what you want, here.

• The constructor for your attributes don't run until the attribute is recovered through the reflection API (e.g., by calling Type.GetCustomAttributes()).

• There's no API or other mechanism for the code in the attribute to "see outside" to what the attribute instance is attached to.

The behavior you're seeing from Unity is likely handled by reflection or something similar: when creating an instance of some type, the type is inspected (via GetCustomAttributes) for RequiredComponent attributes and instances of the types specified by any such attributes found are created and attached to the object.

If you create a wrapper around the creation of objects that you use everywhere, you can implement similar behavior via reflection. But you can't do it from the members of the attribute subclass code itself.