I just noticed that Renderer is not inheriting from Behaviour, but instead it inherits directly from Component. I’m wondering why this is the case. According to the documentation “Behaviours are Components that can be enabled or disabled.” This is the case for Renderers as well, but they have their own enabled flag themselves.
Seems kind of inconsistent and does create problems for a more generic functions.
Or am I missing something?
Best regards,
Johannes
Component doesn’t have an enabled, Not every component can be disabled.
@zombiegorilla Yep I know, that’s why Behaviour exists I guess. My point is, that Behaviours can be disabled and Renderers can be disabled and it would make sense that Renderer inherits that functionality from Behaviour, but it doesn’t.
Behaviour has .enabled and .isActiveAndEnabled. Renderer has only .enabled.
I’ve got no idea what isActiveAndEnabled is, or when that would be false when .enabled is true (or vice versa), so I couldn’t tell you what the deal is.
… is there any instances where you need to get everything on an object/in a scene that can be disabled, or are you just asking out of curiosity?
The documentation is a bit vague, but it should be true if the MonoBehaviour is enabled and its GameObject is active in the hierarchy. Otherwise false.
Who cares? Lots of the built in components inherit directly from Component. Normally it indicates they are a wrapper for some internal C++ magic happening in the engine.
So why does it matter? The components work of you simply add them. If you need to get all components, you can iterate across at the Component level. Where is the problem?
Thanks for the comments!
@Baste It does not really stop me from anything, I was just creating a more generic enable disable script which made me notice the unexpected inheritance. So I guess it is mostly curiostiy why Renderer is not inheriting from Behaviour.
@Kiwasi Hm interesting, I didn’t notice so far. Can you give me other examples? Is the C++ magic an educated guess? I’m wondering if that magic is not possible when inheriting from Behaviour.
Looking forward to getting a better idea about the basic structure underneath Unity 
From memory none of the physics components inherit from MonoBehaviour.
Total educated guess. You can check yourself by taking a peek inside UnityEngine and seeing where the components lead to. The C++ ones are basically just thin wrappers that call through into C++. You could then check out the inheritance structure for each C# component.
Physics inherits from components, and physics is a C++ system. On the other hand all of the UI elements inherit from MonoBehaviour, and the UI is a C# system. So its just anecdotal stuff. But it wouldn’t surprise me if I was right.
@Kiwasi : I took a quick look at Rigidbody and you’re right, it also passes Behaviour and inherits directly from Component.
Hm interesting point. I do see that it does not make sense to inherit from MonoBehaviour, apparently Behaviour itself is also not low level enough. I guess I will dig a bit into Behaviour once I’ve got the time to do so, thanks for the clarification.
Given that the act of disabling a renderer also removes its mesh from the engine’s draw consideration it would seem to make sense that it would follow a different logical path.
Behaviours and Component are largely the same in C++. Behaviour inherits from Component and add support for managers, by default behaviours get added to a BehaviourManager for Update, FixedUpdate and LateUpdate.
Renderer has no need for any managers so we just inherit from Component.
Simples
Are we allowed to do the same thing?
Inherit from Component? No this is C++ side, the C# scripting side is all based on MonoBehaviours.
It would be really nice to be able to attach components to things that weren’t behaviours. Mostly for attaching data to an object about how other behaviours should react to it without the data doing anything.
Now we can do that with MonoBehaviours that doesn’t define any magic methods, sure, but the semantics of a Behaviour is that it… behaves in some way.
Something similar can be achieved with Scriptable objects, although they usually live in the project as Assets or are generated from external data:
https://www.youtube.com/watch?v=VBA1QCoEAX4
Granted, I’m moving more towards this style of data storage from something similar to what you described.