It is how many years ago that all direct accessors (except gameObject, transform, and tag) have been removed from the Component class?
Code:
{
...```
Unity is like:
```[CS0109] The member 'UiTouchableButton.collider' does not hide an accessible member. The new keyword is not required.```
Changed code to:
```private BoxCollider collider
{
...```
Unity is like:
```[CS0108] 'UiTouchableButton.collider' hides inherited member 'Component.collider'. Use the new keyword if hiding was intended.```

EDIT: I forgot to mention that I had this problem in 2021.3.7, NOT in the current 2022.3.19. So the issue seems to be fixed by now - sorry for the confusion.
Right. I donât quite understand some of the cargo cult. Yes, some features are kept and marked as obsolete but still work. They are to encourage people to change as soon as possible but still work. However the component shortcut accessors has been made unusable ages ago. So thereâs literally no benefit at all to carry them along as vestigial parts of an ancient time. Some things they got rid extremely quick, considering their frequent change of the network libraries and solutions, while others are dragged along for no reason.
Most developers who use Unity now probably have never worked with a Unity version where they were still functional. So for them it always was just something weird that doesnât work and causes problems.
Yep, those are all gone in versions after Unity 6, as are many many other obsolete methods/properties too. Glad these specific ones are gone, they were a poor idea which didnât scale well despite trying to serve as a nice accessibility feature. No idea where it all started and Iâve been working here for 11 years!
Looking forward to things like trigger callbacks passing an arg named âcolliderâ and not âcollisionâ or being able to name locals as âcolliderâ.
I tend to prefix method arguments with an âaâ. So hungarian style but not to indicate type information but just the fact that itâs an argument. It solves a lot of common name collision issues and also helps distinguishing arguments from other variables. Though I do understand that most people donât like this. Personally I donât like code like
void SomeMethod(int x)
{
this.x = x;
}
where you have to use âthisâ to distinguish between the member variable and the argument variable. To me thatâs way to messy and reminds me way too much of javascript where this is kinda the norm ^^.
Nice to hear that Unity will rejuvenate the API here and there together with CoreCLR even if that means some breaking changes.
A good C# dev should not have much trouble migrating such things quickly where the compiler complains.
Trying to avoid speaking for thousands of internal devs over the years but backwards compatibility was always important internally, the problem was that when something migrated to deprecated then to obsolete it was then left. I recall there being a procedure that it should be left for no more than 1 or 2 major releases after being made obsolete but that was a guide rather than a policed law so it resulted in a lot of obsolete things being left.
Thereâs definately a huge âtidy upâ operation going on with a major part being focused on removing tech-debt and itâs wonderful to see. Like a nice hot shower if you will.
The most important things in that case would be clear communication about those breaking changes so people donât update their current projects. The Unity Hub should have extra warning dialogs besides the normal upgrade warning to avoid careless upgrades which would result in a disaster.
No, I was annoyed by a warning that was impossible to get rid of, no matter whether you used the ânewâ keyword or not. Read my original post again.
But as others pointed out, that problem was apparently fixed in 2022.x/2022.3.
I see that a lot but personally never cared for it in that context. IDEs that are less than a quarter-of-a-century old can give me all of that context instantly. Itâs why I think the progenitors of Hungarian Notation themselves (Microsoft) stopped using it. Because all of that context is usually either color-coded or right at your fingertips anyway.
Although - I do still use it from time to time specially when Iâm declaring a backing field for an otherwise identically named property.
I agree itâs vestigial, but there you go, sometimes you just wanna glance over it (or make names similar if they share context). I never do PascalCase with it though, thatâs kinda dirty lol. But I do like having some low-level internal functions be snake_cased, so there is a lot of room for personal quirkiness I guess
That is of course a valid suggestion - but IMHO it is never a clean solution to simply suppress warnings you donât want to see
What I meant by âimpossible to get rid ofâ is, no matter what you do to your code (except #pragma or refactoring your variable name), you will get either CS0109 or CS0108.