Can I name by Rigidbodies "rigidbody" yet?

[Baste]

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?

[brunocoimbra]

@Baste

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

[TheZombieKiller]

@Baste

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?

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.

[rz_0lento]

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.

[Deozaan]

@TheZombieKiller

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).

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() 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.

[print_helloworld]

@rz_0lento

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.

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.

[Baste]

@TheZombieKiller

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).

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.

[thelebaron]

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”?

[runner78]

Unity-Technologies/UnityCsReference/blob/master/Runtime/Export/Scripting/Component.deprecated.cs

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

[runner78]

@runner78

https://github.com/Unity-Technologies/UnityCsReference/blob/master/Runtime/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.

[Vagaus]

We have not removed these properties yet because they are required for ApiUpdater to work.

Since these properties were heavily used we would like to keep support updating them to make it easier to migrate old code (keep in mind that there are lots of educational material, tutorials, videos, projects, etc out there that still references these properties).

[Baste]

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”.

[vveisard]

@Vagaus

We have not removed these properties yet because they are required for ApiUpdater to work.

Since these properties were heavily used we would like to keep support updating them to make it easier to migrate old code (keep in mind that there are lots of educational material, tutorials, videos, projects, etc out there that still references these properties).

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

[Ray_Sovranti]

@SINePrime

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.

[Vagaus]

@Baste

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.
.

the goal is not to get it working, but to ease this process

@Baste

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”.

It is a little bit more complicated than that (for example, you may have an existing, unsupported assembly, referencing these members) but, yeah, it may worth exploring this idea.