In 2014, Unity published the Custom == operator, should we keep it? blog-post.
Today I ran into the this problem again, which happens every now and then to me. Funnily, I ran into the same issue that has been mentioned in the blog-post:
What’s the status of addressing this issue?
It didn’t happen in Unity 5.
Fixing this would probably be a breaking change for a lot of projects. My guess is you might see it in the next major upgrade (ie 6.0). You might not either.
I’m honestly not sure the ‘correct’ behaviour would be better. The current behaviour is more intuitive. A null check would be meaningless if you had to follow it up every time with a second check of ‘no I mean is the object really available for me to use’. Which is pretty much what the is destroyed check would amount to.
Edit: For the specific optimisation around lazy initialisation of cached variables, you can alway use object.ReferenceEquals
Geezus H. Crapinahandbasket. Half the folks here are artists. Can you code mongers please stop it with the low level BS. Intuitive beats alot of mumbo jumbo horse molarkey hands down when developing. We don’t have time to take 4 years of compsci just to throw jargon around and pretend we are smart. I see the problem as toooooo many .NET devs jumped over and now want to force their practices down the throats of folks who are quite fine developing for several years without the .NET “best practices” interfering with us understanding just WTF we are writing to support our art. I can write any game mechanic and do it without losing performance or windows corporate forms best practices. I understand the Unity component ideology just fine and can use it to definitive advantage to rapidly build frameworks and components I need… I suggest ya’all get used to it and stop whining for C++ API and to conform to .NET windows corporate form codebase. We do what you want and all of a sudden we get null reference exceptions and can’t find them unless we use unnecessarily verbose snippets of code that make no bloody sense… Is it there…no…&&but is it not really there…yes… WTF???
Huh? Are you saying that devs should not ask technical questions? Or that Unity should not have a technical blog post to cover a technical topic? Or that people are wrong to want the == operator to operate as would be expected?
All sound ridiculous to me.
No one is “pretend we are smart”, it makes perfect sense to use the terms and nomenclature that fits the topic and target audience. Anything else would be crazy.
I really don’t get what your complaint is really about.
This is absolutely inappropriate! Unity’s implementation can lead to very weird and unexpected cases. This has nothing to do with technical mambo jumbo or however you want to call it. There are pros and cons for both and as such a discussion about it should be allowed.
http://forum.unity3d.com/threads/null-check-inconsistency-c.220649/#post-1475959
Nope…none of what you “interpreted” I said. My complaint stands as is without fallacious interpretation such as your attempt.
I think it is inappropriate for this to break so many others work for such a small thing that makes little difference in performance unless called in the Update loop, just so some .NET devs can play compsci jargon games and shove their “best practices” down everybody’s throat. I read every comment in the blog post. Rune’s makes absolute sense in his commentary. Frankly there are much bigger fish to fry for Unity than this “is it there…nope && does it exist yes/no”. I use if (!objectInQuestion) {} myself. I see the issue of if you use this .NET paradigm then you may get null reference exceptions that point to nothing. You want to talk about a nightmare for an artist developer?
With the very intuitive implementation, some weird cases appeared as mentioned in my previous post. So in order to be intuitive, it became the exact opposite in others.
I am not talking about this .NET paradigm at all. But is it intuitive for an artist developer to use a workaround like
if (obj == null) {
obj = null;
}
in order to the the correct results?
Uh, for the record - I think there’s a little misunderstanding.
if( go ){ }
This is an implicit conversion to boolean. This is not the == override they’re talking about.
They’re talking about an override of ==, which means that the == operator is doing a set of additional checks.
Changing this would not stop your code from compiling or change your syntax. It would change what the equality operator does and how it relates to destroyed or null objects. It’s honestly a very technical change that not many people would understand or even be aware of. Although in some corner cases it may break existing code.
At the end of the day, the problem is that there’s a possible desynchronization between the GameObject we see (a wrapper) and the GameObject the engine references. This is going to be a pain in the ass no matter what and it’s going to lead to tons of mistakes from coders (either in not checking go.destroyed or in misunderstanding the == check).
Personally, I prefer the gameobject.destroyed field, if only because it makes the structure and problem explicit. By simply having the property there, you’re helping to make the user aware that there’s a potential issue in the first place. In general, I prefer making the user aware of these things rather than hiding it for 95% of the cases, while causing very unexpected behaviour in 5% of the cases.
Make an extension method for MonoBehaviour equality that routes the check through System.Object.ReferenceEquals (essentially what’s done when you don’t override the == operator). It might complicate the code a little bit but not as much as for people who’ve set up entire projects based on Unity’s custom behavior.
The implicit conversion from MonoBehaviour to bool is stupid though. So many unnecessary bugs.
Well I’m sorry but your rant is rather incoherent and my “fallacious interpretation” was my best attempt at deciphering what on earth you’re complaining about. Maybe your rant makes sense to you with the context ‘you’ had in ‘your’ head.
It’s best to leave the programming (and programming discussions) to the experienced programmers. Please stick with Playmaker if you can’t understand why overloading == is a bad idea.
It’s not that bad. I actually enjoy not having to do an extra MonoBehaviour.destroyed check.
There are better ways to make it convenient. The foundation should be made solid, then add convenience on top of that.
Maybe add === operator? 
Joke, bad idea.
Go tell that to Rune. Ya know… the developer who has worked for unity since way before you showed up. Smarmy BS line IMO. The problem with leaving the discussion to programmers is they are not the only ones using this application. Next time you open your mouth about art should I stick my foot in it for you?
If a GameObject has been destroyed, it is conceptually no longer available for use. So a null check should return null.
I’m genuinely curious as to what the use case is for a null check returning false on a destroyed object. I would then end up with this on every single null check. Which just seems a waste.
if(myGameObject != null){
if(!myGameObject.isDestroyed){
// Do something with the object
}
}
No, but the programmers are the unfortunate ones who have to deal with this type of nonsense all day. You at least have other jobs related to the game development task that you can shift focus to if you become stumped. At least until you have no other choice but to solve it.
If this sounds like a rant, that’s because it is. Unity should have done it the intuitive way from the start rather than require us to change our mentality for one situation only to reverse it down the road because they discovered it was a stupid choice from the beginning.
Everyone making simple apps can easily say that it’s worth keeping it how it is. Some people want to push computers to the limits, and those performance issues become a problem. Especially when you have to do a lot of ‘==’ checks.
Fortunately for me, the vast majority of my code isn’t MonoBehaviour-derived (only about 15% uses MonoBehaviour, and I don’t need to do ==s on those) and so this isn’t super relevant.
It still annoys me when people who make small apps selfishly ask for features that will slow it down for people making more performance-critical applications, just so they don’t have to type an “&& !gameObject.isDestroyed” at the end of an if condition.
I gave you a case in which the current intuitive implementation is not intuitive at all. For coders it can be very tricky to deal with that kind of situations. I wasted days because of “null != null”. The developers who work for Unity usually seem to prefer solutions that look very easy at first, but may in the long run turn out to be tricky if the functionality is used in advanced cases. E.g. extending the Unity Editor is very simple… unless you do something advanced.
For me personally, “==” is something like the magic functions (Start, Awake, …). They were implemented when the Unity developers didn’t have much experience with .NET. Finding out that Start and the other magic functions were not such a good idea can easily be found out here in the forum, because beginners (and even experts) frequently struggle with them because they make typos, which would not be possible if they would have been implemented properly.
For “==” on Unity objects, it is certainly not that obvious and for simple cases it is really not a big deal. But there are cases in which advanced users waste a lot of time, because everyone works under the assumption that “null == null”. Unfortunately that is not the case in Unity.
For strings, there is string.IsNullOrEmpty (…) and something like that could be used for game objects as well. I even believe it would be better, because everyone could sees directly that something special takes place based on the syntax and doesn’t assume it is just a null check.
A good thing is that the API updater could easily handle that. The new API for it would not be more difficult, everyone would understand that not an actual null check is being made and the special cases would not exist anymore.