Prevent subclassing of the Robot object

[RealOrangeOne]

Teams will often try and subclass our robot to add their own functionality on top of it. Not only is it bad practice, but it can often conflict with the inner workings of our own classes.

Instead, teams should be encouraged to wrap our class. Guidance on that will come as a future docs PR. However for now, prevent subclassing.

[RealOrangeOne]

I'm intentionally holding off merging this until we have relevant documentation to point teams in the right direction. Without that, I think this PR is just a hindrance.

[PeterJCLaw]

Are there some notes somewhere on why we're trying so hard to prevent people doing this? I'd like to better understand the motivations for this (not least because we'll need to also clearly communicate this to mentors).

Subclassing an API's class to extend it or modify its behaviour is a very common thing to do and is often explicitly the expected path. Discouraging it if we have specific reasons to do so may be fine, however the description here seems to be much more along the lines of the usual caveat emptor style stuff which is just the normal course of things.

I could understand a small warning in the docs which said something like "beware that when doing this you should be aware of these risks ..." and possibly a note on what specifically to look for, but the lengths being taken here (raising an exception when subclassing) seem rather extreme, especially given the relative usefulness of subclassing as an approach.

[WillB97]

There's an accompanying docs update to explain the change here srobo/docs#677

[PeterJCLaw]

There's an accompanying docs update to explain the change here srobo/docs#677

Thanks, however I'd seen that (I almost posted my comment there). The things that PR mentions are the sorts of things I alluded to which anyone subclassing should be aware of as risks, however they don't strike me as good reasons to directly discourage subclassing (which teams have been doing for a long time, usually without issues) nor put in place technical measures such as those in this PR.

FWIW: I can see value in suggesting the alternatives and making people aware of the risks, and even using the typing.final decorator. It's the stronger bits and raising an exception which I'm looking to better understand.