Feedback Can I name by Rigidbodies "rigidbody" yet?

The built-in rigidbody, camera, light, animation, renderer, audio, etc. properties in Component was deprecated in Unity 4 or 5, but they're still there, half a decade later, with [Obsolete] markers. This means that there's a ton of very useful variable names that I can never use, since they conflict with a bunch of other stuff.

Why are they still there? It's not for backwards compatibility, since the properties has been throwing exceptions for years. Is there any reason why you don't just delete them?

 

They need those there to be able to run the API upgrader AFAIK, but yeah, I would say that it would be better if they just require to jump between each year version before updating to the latest one

 

Can you provide some examples where this causes problems or errors? You can use the "new" keyword on a field to use those names, and using them within a method just results in a warning (which can be suppressed in several ways).

Absolutely not disagreeing: these should've been removed ages ago, but I'm curious about the situations you're encountering issues with.

 

I'm bit on a fence on removing things that don't matter for most. I've always liked that I can pick any ancient Unity project and it does give me feedback on what I should change to make it work again when I try to run it on latest version. For example there's one Unity 3.x project that I can still make work on 2020 cycle just by following the hints from the obsolete messages.

 

I use a cached MonoBehaviour which was originally written when these properties existed in Unity but now that they're obsolete I face two problems:

1. I get warnings every time I build. If I use the "new" keyword, it tells me I don't need to. If I don't, it tells me I do need to.

2. If I upgrade a project to a new Unity version, the API upgrader changes my valid property code to e.g. myGO.GetComponent<RigidBody>() instead of just myGO.rigidbody. In other words, it makes my code perform worse by doing lookups every frame rather than accessing the cached references!

If Unity would just remove these obsoleted properties then my cached MonoBehaviour script would work fine.

 

That doesn't sound like a good argument for keeping obsolete properties like those, just to be able to open old projects and know when something needs to be replaced. If the obsolete properties are removed you will know either way. It doesn't seem fair that the ability to open old projects would take precedent over being able to use those names as if they're keywords. They used to matter at a time when a transition was happening, but today that point is moot.

 

I mean the situation I'm encountering issues with is that I have to add the "new" keyword and suppress warnings.

They also strip the properties out in builds, so you end up with new warnings about "new keyword is not necessary" there, which is just fantastic.

 

I've been wanting to make a post about this annoyance for ages(thanks for doing what I have been too lazy to do). Couldn't this just be an editor script, in a similar vein to how you update materials to either renderpipeline from built-in, instead of being these "reserved keywords"?

 

https://github.com/Unity-Technologi...time/Export/Scripting/Component.deprecated.cs

They only throw an exception anyway, removing shouldn't be a problem, updater should still work.

 

Small mistake on my part, an autoupgrade would no longer work, otherwise custom properties with the old property names would otherwise be rewritten.

 

But unless you have an absurdly simplistic project, updating from the last version where these were supported (4.7, I believe) to 2020 won't work anyway.

I'd really love to have a switch I could turn on to say "I'm a professional developer, not some beginner hobbyist making their first game with a tutorial from 2015 for some reason, please let me use these variable names".

 

I'm confused. What's the purpose of marking them as obselete if they are still being supported? Why discourage their use?

 

They're not supported by the engine, they're supported by the script updater.