koobas.hobune.stream
Not every Class in the API is derived from the "Object"-Class, so what are they?
I had been under the impression that in ObjectOrientedProgrammingLanguages every class would be an object. And I thought the API-Page for "Object" supported my assumption:
Object: Class. Base class for all objects Unity can reference.
But when you click on "Runtime Classes" (let alone "Editor Classes") there are a whole bunch of Classes that don't inherit from "Object". But if they aren't Objects, what are they? And how do you properly refer to them? "non-object-classes"?
Will all Objects apear in the Assets-Manager? And vise versa: Will everything in the Assets-Manager be Objects? (Are the folders objects, too?)
(Also see http://answers.unity3d.com/questions/1958/fundamental-difference-between-class-and-object for some insightful answers on a very closely related question that came to my mind after asking this one)
Thanks & Greetz, Ky.
Hehe, that's actually one of the things I find a bit confusing in the Unity-API ;-)
Notice that they say "Base class for all objects Unity can reference." (emphasis added). So it's not the "Base class for all objects" but the base class for those objects that "Unity can reference" (which, admittedly, can seem a bit mysterious - what exactly does it mean that Unity can reference those objects? ;-) ).
In my opinion, what they call "Object" should rather be called "UnityObject" because it's not really just the generic object: In .NET/Mono that generic object that everything inherits from is called System.Object, and in fact, Unity's "Object" inherits from that - and all objects in the Unity API also inherit from that, even though it's not explicitely stated. What you see as "Object" in the scripting reference in reality is actually UnityEngine.Object. That's the full name of it - but that's something you can hardly see from the API-documentation, but you may have noticed that in Unity C# scripts, you always need
using UnityEngine;
... which is what makes all the classes from that namespace available to you (and in fact, pretty much all the classes you find in the scripting reference in the section Runtime classes live in that namespace, String being one noteworthy exception - string is a .NET class that actually lives in the System-namespace, so that would be System.String when you have it fully qualified ... and in fact, it is a lot more powerful than what's documented in the scripting reference: see the real System.String ... but don't get confused ;-) ).
So, this UnityEngine.Object is a game engine specific class that has an instance ID and that can be looked up with FindObjectOfType and FindObjectsOfType. Also noteworthy is that these game engine specific "Objects" can be (and have to be) explicitely destroyed if you want to get rid of them: Object.Destroy. Usual objects automatically get cleaned up by the garbage collector when you no longer reference them from variables. And those special Unity "Objects" can (and must) be instantiated with a special method (which is usually executed by the editor): Object.Instantiate.
Usually, in object oriented programming (or at least: in C#), you instantiate objects with a language feature - not with an API feature (forget about Singletons and Factories for a moment; that's advanced stuff ... less advanced than Unity's "Objects" but more advanced than my example here ;-) ).
You can say:
Random myRandom = new Random();
In that case new is a language "feature" that instantiates a new object. Random is an object, and it obviously doesn't inherit from Unity's "Object" class. It's not even aware that this class exists and can't be aware of that because it comes from an API (.NET/Mono) that is "below" Unity (in other words: Unity is built upon it, not the other way round - that's "package dependencies" in oo-speak).
I think one more thing that's important to know about those Unity-specific objects is that they don't only exist in the .NET/Mono space but also have their "counterpart" in the native Unity game engine. In other words: Those "Objects" are much more than any usual C# object, which explains some oddities (like you get very weird behaviors when you directly instantiate those ... see the forum posting I linked below for an example). And I think this is also what they mean by "objects Unity can reference". The low-level game engine "knows" about these objects and can access them because they live in both worlds (the native C++ engine world and the scripting .NET/Mono world).
So, in the end, all classes that don't inherit from UnityEngine.Object are simply Mono-classes, and if you instantiate them (with "new" in C#, without "new" in UnityScript), you get Mono-objects (which I sometimes call "pocos" - plain old C# objects ... which I derived from "pojos" - plain old java objects, a term from the J2EE context; or simply "vanilla objects" ;-) ).
What's called "Object" in the Unity-API is not just a C#/UnityScript/.NET/Mono-object but a very special kind of object in the Unity-space, actually, I'd say it's something very magical ;-)
Finally, not all "Unity-objects" appear in the Asset-Manager - but I think you could say that everything you see in the project pane (what you refer to as "asset manager") is represented somehow as "Unity Object"; except for folders (and things that Unity can't import ... but I haven't tested that - might be things that Unity can't import end up just as instances of "Object").
Btw, when I first learned scripting with Unity, I ran into an issue that appeared extremely weird to me, which is somewhat related to this (and I was really confused back then): Huh? varName != null is false, when varName is not null?; in particular, see Keli's answer.
Also related to this is this little statement in Overview: Writing Scripts in C#: 7. Avoid using the constructor.: It's important to understand that this refers speficially to MonoBehaviours - part of it probably refers to anything derived from UnityEngine.Object. It does, however, not refer to any of those objects which are instances of classes not derived from UnityEngine.Object.
Thank you for your excellent answer, as always =) So I'm not plain stupid after all! Yay! =D But now I really regret spliting this topic into two questions... :( I edited my question in the other thread ( http://answers.unity3d.com/questions/1958/fundamental-difference-between-class-and-object ) $$anonymous$$aybe, for convenient's sake you could re-post this answer there and we delete this question entirely?
Actually, I think it's best to simply link the two questions. You already have a link from the other question to this one and may consider adding a link from this one to the other (in the actual question text). I actually find the two questions reasonably different ;-)
jashin's answer is great but i want to note: 1 hashtable and arraylist are not unityengine classes and they are in System namespace too. 2 when you want to get a reference to any of the items in project pain with any class like selection you should use the objects property. in documentation it says that "this will return scene objects and just active objects" but it really returns references to folders and scene files. when i was testing the pro i made a script to create asset bundles and saw this. i reported this as a bug in documentation. unity really needs a better documentation that describes all of the inner workings of the engine. all other engines do this.
