Why deprecated component getters are still there?

Simple question. Components have built in getters for various other components like:

this.rigidbody;

or

this.collider;

, however they are deprecated since I started messing with Unity (at least 2019.1). Right now Unity 2022 is on the way, but they are still not removed and don't allow to name properties like human. Could someone explain reasoning behind this?

 

Because removing them will break ancient projects that upgrade. You can reuse these names with the new keyword in your properties.

 

Whose ancient projects? Unity tutorials? or you mean ancient projects of developers left for 5+ years without progress?

 

I don't know. I just recall a staff member mentioning why a couple of years ago.

 

This is the keyword

 

Unity has been around in HEAVY use for a long time. As a consequence there are millions of little snippets of code example out there: stack overflow, Unity answers, this forum... there's a LOT of code out there.

There are even still people coming in here posting UnityScript (Javascript-esque) examples and asking why they don't work. UnityScript has been deprecated for five years at least.

Fortunately if someone digs up an old C# script that uses one of the above properties, after they paste it in and let Unity stare at it, Unity simply asks if they want to do an API upgrade and 99% of the time the issue is resolved and you never need to know about it.

Otherwise half of the example scripts still out there would just fail to compile and people would be stuck.

IMNSHO, the namespace pollution is barely an inconvenience. Besides, a variable named

camera

or

audio

or

collider

is just waaaaaaay too generic anyway. Add some value and name the thing better!

mainCamera

,

audioSource

,

floorCollider

etc.

 

I completely understand this side of the coin, however at the same time this is partly the reason why this happens. If we keep ancient scrolls around we should not be suprised someone stumbled upon them.

My point is, if someone resurrects 5+ years old project, then most likely it requires a lot of changes to adapt with new API and this.collider is the smallest problem when missing - I would even say that jumping 5 major versions sounds like bad idea. The same with old tutorials, if it's so old then maybe it requires upgrade, so people use round wheels instead of square wheels.

Yes people would stuck, but they stuck anyway. If someone is smart enough there should be no problem to find solution and in case someone is green begginer it means he shouldn't use that tutorial at all, becuase he might learn bad practices.

Ultimately yes, this is not big deal, but I don't see any reason to make complicated names for this sake - simplicity wins.

 

Over decades of upgrades to all sorts of software we've figured out that old stuff should be kept as much as possible. Deprecated features should only be dropped if they cause a big problem or if keeping them is a ton of work. That's because actual real-life experience has shown that many paying customers use very old features, and the more changes they're forced to make, the greater chances they switch to a competitor's product.

In other words, there are way more paying Unity customers using myTransform.rigidbody who would be puzzled when it stopped working, than ones unable to fix errors caused by declaring

Rigidbody rigidbody;

.

 

IMO they should just move the deprecated properties to a partial class. Then put the partial class into a package. Anyone that upgrades ancient old projects, have the upgrade process automatically add that package.
There's not much worth keeping them around. I rather have breaking changes than sitting with ancient old API that never gets used. The API upgrade process already takes care of some of them too. The old API is just an annoyance in auto-complete

 

I love partial classes and I love this kind of solution as a precursor to refactoring a class, at least to physically break it apart.

Alas however, in this case partials won't help you: those are properties provided as native engine code hooks at the Component level, which Behaviour inherits, then MonoBehaviour inherits, then your class inherits.

In fact, here they all are in the assembly browser, right alongside others we have agreed are useful enough to keep forever. In fact, the only ones NOT deprecated are gameObject, transform and tag !



As much as people carry on about how desperately we must remove these (despite the new keyword work-around), there's always 10x more people howling and moaning about the boolean operator override at the UnityEngine.Object level, and that is even LESS likely to be removed.

 

DOTS is free from the sins of the father before time; when the World was Gooball and the disciples of Unity numbered but three.

 

Well, for sure I do not represent majority of users and I think it's fair point by Owen, I just thought that this is point of deprecation, to create new API, let users know about that change, give them some time to move to the new one and at the end remove old API.

 

The new API is DOTS though. There's no mistaking Unity's long term intent here. So I don't think there will be any movement on it. Because of two things:

1. You can still use those variable names.
2. The OOP design means absolutely no perf gain or meaningful memory will be saved by removing these properties.

So basically it causes more harm to remove them. So the only reason for removal would be to satisfy your own preference, rather than a technical need.

 

i would not consider the new API DOTS, its just a other set of tools to use in the engine where it makes sense for a usecase and versioning wise is handled completely different.

On the original topic, long deprecation windows, or leaving stuff in the deprecated state forever makes sense when you know there are clients with working with old code bases that would not be happy about having a bunch of maintenance work hoisted on them for no reason.

 

If a member is deleted, will the API updater not be available?
Also, if there was an option to check for errors each time and notify us that an API update might be needed, it would save a lot of confusion when a newbie is introducing old code.