koobas.hobune.stream
The question is answered, right answer was accepted
MonoBehaviours with same name (different namespaces) in same script
What I want
I am trying to work on different versions of same MonoBehaviour class in Unity but I want their name to be same and in the same folder.
What I do
I created the c# script say "test.cs" I defined two namespaces in them "test.A" and "test.B", and add the code of the MonoBehaviour class "test" in both namespaces, save the script and open Unity.
test.cs :
using UnityEngine;
namespace test.A
{
public class test: MonoBehaviour
{
public Type1 object1;
// Some code
}
}
namespace test.B
{
public class test: MonoBehaviour
{
public Type2 object1;
// Some other similar code
}
}
What I expect
I expect unity to compile both the classes differently and I be able to add these classes differently in "Add Component>Scripts>" + "test.A>test" or "test.B>test"
What I get
Unity skips the namespace "test.A" and I only get to add the class in "test.B"
What I want to know
Why is this happening in Unity?
Is there a way to do this or will I have to go the other way by creating different scripts for different version of the class with different names?
That's because the file name has to match the classname. So there can only be one class in one file. That file asset in your project is your link to the class. You can not have one asset represent two different classes at the same time. What "might" work is when you place them in two seperate files in different folders, both with the same filename.
Unity is mainly an authoring software. Unity can't compile your code "differently". All classes from one compiler group is compiled into one assembly. In general any C# compiler can only group things based on files. If you include a file when compiling an assembly all of its content will be compiled into that assembly. You can not somehow make the compiler and compile one half of a file in one assembly and the other half into another. Every "asset" in Unity has to have a direct link to an asset stored in your project . For scripts that's the script file which is represented as a MonoScript instance (only inside the editor). One MonoScript can only represent one class (No matter if it's a MonoBehaviour, ScriptableObject or Editor derived class).
Of course Unity could have introduced a new sub asset which would appear below the actual script asset in Unity like it happens with FBX files for example. However this has grown historically. In the past there was no support for namespaces at all. So it was completely impossible to have the same class more than once.
IMHO there's no real point in Unity to use the same class name twice. It just creates confusion. It also doesn't allow for easy switching. Since they are in different namespaces you have to adjust the namespace everywhere you might access your class. Just having the same name does not mean they are connected in any way.
A namespace is not meant to distinguish different class purposes, that's still the duty of the class name. A namespace just groups things into categories which somehow belong together. You might want to read through the naming guidelines for namespaces for .NET. Specifically
DO NOT give the same name to types in namespaces within a single application model.
Keep in mind that those are not rules but guidelines. Though they server a good purpose and have evolved from a lot of experience. Even Unity has "violated" some of these guidelines (the Random class for example). Though Unity is a very specialized subset of .NET development. So it's fine to have slightly different rules in that domain.
Thanks for your answer, I got to learn much more from your answer.
@Bunny83 I yet have one more question.
Why must $$anonymous$$onoBehaviours have same name as their file?
To be honest we don't really know the exact technical reason behind this. It might be related to how things are serialized. Apart from that it's the most natural thing since, as I mentioned, the script file asset in your project is like a "handle" for the class inside the file. So when defining a a $$anonymous$$onoBehaviour named "$$anonymous$$yAwesomeClass" and that class is bound to the script file it is defined in, the most logical name choice for the file is that class name.
Another reason that just sprung into my $$anonymous$$d is that in the past we had 2 additional .NET scripting languages. One was Boo (a phyton inspired syntax) and the other was UnityScript (a Javascript inspired syntax). In UnityScript you did not need to define a class because it generally treated the file and its file name as a class. UnityScript often had a very short syntax to define basic things. UnityScript is no longer supported however if you want to know how it used to look like, this Unity wiki article covers a lot of it's syntax.
Deprecating UnityScript was one of the best changes in Unity. They now focus much more on what C# can actually do. It was a huge burden that was carried along. Though a lot of the early design choices they made are still stuck with Unity. They definitely could change this behaviour, however such changes would be breaking changes. In other words most existing projects would need to be modified.
