@Nifflas IIRC uou can get around it with the null coalescing operator (??) or conditional call operator (?.) since those don’t call == internally. We have unspoken rule that you can’t use those operators in Unity code because of it.
@Nifflas yeah, it would be very breaking. To be honest, I don't even know how easy it would be to change implementation, because (I don't know if you're aware) it stems from Unity's architecture itself.
@oldschoolpixels I can't see why that would be hard to change tho (given it's OK to break all previous Unity projects). Remove the fake null operator override, and expose an "isDestroyed" property that returns the exact same information as a bool.
I can use ReferenceEquals to check if it's true null. But, how do I check if it's fake null? Comparing the output of ReferenceEquals against the result of the fake null check?
It just messes with my head so much whenever the fake null check is involved. Usually code is clear, but I can't build a mental model whenever dealing with this :( Things aren't what they're supposed to be and my brain is unable to process the information.
I'll probably add a "IsFakeNull" and "IsRealNull" extension method. But ideally, I need to figure out a way to output an IDE warning whenever I accidentally compare an UnityEngine.Object against null too.
@toerror@runevision Wait, isn't that severely going to mess with any collection that uses the hash code to find the object, like a Dictionary or HashSet?
@toerror@runevision It's a performance loss for binary search with lots of instances sharing the same hash code. Starting to form an idea why this is happening tho. Overriding the equality check also requires overriding the hash code. And they shouldn't have different hash codes if comparing their equality should return true, otherwise collections will break. So Unity sets them all to 0.
This is a bigger mess than I anticipated.
Why didn't they just not override the null check? Oh my god!
@toerror@runevision So much stuff only to be able to check if (x == null) to see if it's destroyed.
Doesn't make sense for a beginner who doesn't know what null is. isDestroyed would make more sense. Current implementation heavily distorts a learner's concept of when a reference can become null (normally it cannot if you're referencing the object).
Doesn't make sense for an advanced programmer like me who values accessing the underlying information. isDestroyed would have made more sense too!
@Nifflas@toerror It's not only a check to see if an object that did exist before has now been destroyed. It's a check if it exists at all. Your isDestroyed property suggestion would throw a nullreference exception if the object was never assigned. I think an Exists() method could be implemented as an extension method, but I don't think those existed back when Unity made its fake null implementation.
@Nifflas That's super verbose and I'd be super annoyed if I had to do that in every case where I can currently just check for (fake) null. You're asking so much code that's simple to be made more complicated, just so that your own use case that's so complicated you cannot easily explain it here would be simpler for you.
@runevision I edited the post. We can have an IsNullOrDestroyed method for that. Like a string has IsNullOrEmpty - which is how it's supposed to be done. Don't sacrifice consistency and accuracy for convenience.
The fake null check has been driving me insane for years. I want that goddamn thing gone and I'm ready to have every single Unity project broken over it.
@Nifflas I'm the opposite - I like the fake null check, as I just want to know if the object exists or not. If the C# object exists but the backing native object is destroyed, that's never of use to me. And I've never encountered a situation where the fake null check is an issue. Kind of curious what the situation is for you, where it is.
@runevision It's too much to explain here, it's about the part of the code that tracks stuff and verifies everything is correct. LinkedLists are involved.
I don't do that sort of thinking though. When I ask if something is "null", I'm not asking if the object has been destroyed. I'm literally asking if the reference is null, and ONLY if the reference is null.
I can't build mental models if the meaning changes. I deal in absolutes. I guess I'm a Sith Lord of Unity users.
@runevision Anyway, before I do anything else, I should figure out a way to add a compiler warning whenever I do a fake null check. Just remove the ability to do it for myself.
Then I'll start implementing extension methods that behave the way I want.
@Nifflas@runevision Could you not just do your own equality operator overload and mark it obsolete? Worst case the compiler will ask you to be explicit on which of the two to use, which already achieves your goal?
@AngryAnt I'm working in my own namespace, but I am using the UnityEngine one in my scripts. Otherwise I can't access UnityEngine.Object which has the overload I'm trying to prevent myself from using.
Hm. Yea sorry I was misremembering that recent C# versions had added the ability to do operator overloads as extension methods - that still appears to not be allowed and the places I've needed it I've relied on patching.
@runevision We wrote our own cecil-based setup which I really should get around to cleaning up and releasing, but there should be other nice implementations around.
At some point Unity added what they call a "weaver" for their multiplayer stuff - also doing cecil-based patching. Perhaps reusing that is shortest path?
@JeremiahFieldhaven@runevision Haha, yeah :) I think I'll proudly wear that title! I do want to restore order to Unity, even at the cost of ruining previous projects made with it. Unity needs to conform!
Add comment