Refactor MonoBehaviour into Component.

[Tryibion]

Refactor MonoBehavior naming to Component for a better understanding of what it is. Keep MonoBehavior class as a child of Component but mark as obsolete.

[michaelsakharov]

We've looked into this as a past, but its not a free change, it breaks some stuff with reflection.
And like GetComponents on Monobehaviour doesn't return things made without using Monobehaviour.

And since most our users are coming from Unity, and its just a small naming thing, We've decided to stick with Monobehaviour to help with transitioning from Unity.

[Tryibion]

Unless I am missing something reflection and GetComponents seem to work fine with the changes I made. I did keep the MonoBehaviour class as a child of Component, so files from unity would still compile, but would throw a warning to use Component. I am not a fan of the MonoBehaviour naming when everything else for working with them is called Components.

[michaelsakharov]

GetComponent<Monobehaviour> wouldn't return components that don't inherit Monobehaviour but only Component.
So, while Monobehaviour exists, its not fully interchangeable with Component

So if we did this, I feel we should just drop Monobehaviour all together, make it a clear compile error, Multiple people have requested this change so maybe its worth doing now before 1.0 drops, and just tanking the Breaking change.

[Tryibion]

Ah, I see what you were referring to now.

[dimmerly]

+1 for Component, MonoBehaviour makes no sense when Prowl uses CoreCLR, it's better to rip the bandaid now rather than later.

[michaelsakharov]

This is done