You just gotta love Unity... -.-

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.```
![](https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f926-200d-2642-fe0f.png)![](https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f926-200d-2642-fe0f.png)![](https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f926-200d-2642-fe0f.png)

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

Yeah it’s weird. We’re just used to not declare fields called collider, camera…etc

I think I saw a discussion where they plan to finally remove them, probably in Unity 7+.

4 Likes

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.

3 Likes

Wait… what version is OP on?

I don’t get this when I use the ‘new’ operator like OP shows:

I’m on 2022.3.18 (LTS)

2 Likes

Same. I do see CS0108 when I don’t include the new operator both with VS and Rider. I’m on 2023.1.11.

Using it with “new” is perfectly fine. OP is probably annoyed by having to add that keyword.

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

9 Likes

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

1 Like

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.

1 Like

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.

8 Likes

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.

1 Like

To be clear, I’m talking about obsolete not deprecated. Deprecated still work, obsolete don’t or shouldn’t. :slight_smile:

Very good point, sorry I forgot to mention the Unity version.
The problem occurred in 2021.3, and it indeed seems to be fixed in 2022.3! \o/

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.

1 Like

My personal method to fix this has always been to take the microsoft approach. Class variables are Pascal case, locals are camel case.

void SomeMethod(int x)
{
    X = x;
}
3 Likes

You can perhaps use

#pragma warning disable IDE1006
...
#pragma warning restore IDE1006

Obviously replace the warning code with what you’re getting

2 Likes

And (edit: private) class members fields have a ‘_’ prefix (in my case), so

float _val;

public void Assign(float val)
  => _val = val;

Another way when assigning a bunch of vars in ctors is to do a value tuple assignment.

float _x, _y, _z;

public MyVector(float x, float y, float z)
  => (_x, _y, _z) = (x, y, z);
3 Likes

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.

public float MyValue => _MyValue;
float _MyValue;
3 Likes

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 :slight_smile:

1 Like

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

2 Likes