ambiguous reference with Object type

Hi everybody,

I have a problem with types. I'm starting up to deal with c# language. When I try to compile this function in C#...

Code (csharp):

1.    
2.     public Object searchAsset(String key) {
3.         return assets[key] ;
4.     }
5.  

An error ocurrs:

`Object' is an ambiguous reference between `UnityEngine.Object' and `System.Object'

Is there any way to fix this ambiguity, or I need use other type?

 

You can fix it by specifying which of the two object types you need. In this case, it appears that 'assets' is a hashtable, so in that case it is 'System.Object' (or the shorter: 'object') instead of 'Object'.

I personally prefer to avoid 'using System;' altogether.

 

Solved: I deleted "using System;", and I made a little change:

Code (csharp):

1.  
2.     public Object searchAsset(string key) {
3.         return assets[key] as Object;
4.     }
5.  

Yeap, you're right. Thanks!

 

Not a lot of help if you **really** need to use something in System (which is rather often).

 

Actually it is a solution since you don't have to use a using statement in order to use something from the System namespace. You can always use System.XXX whenever you need it. It's usually not that often. The System namespace mainly contains generic .NET stuff. The only things I could see you may use from time to time is the System.Serializable attribute, the predefined delegate types System.Action / System.Func (and their generic versions) and maybe DateTime.

Including the System prefix isn't really a big issue as the namespace name is rather short. It makes it also more readable, expecially when you have ambiguous types. I would not rely on a using alias at the top of the file since in a Unity project "Object" usually refers to UnityEngine.Object. It's all about expectations and readability. Most important things from the System namespace have global alias names like string, int, byte, object, ...

Also keep in mind that subnamespaces do not have this issue. So you can use

using System.IO;

, you just want to avoid the System namespace itself. There are just too many name collisions between UnityEngine and System. Another common issue is the Random class. If I really need to use System.Random I just write it out.

Of course there may be some situations where you have to use a lot stuff from the System namespace. However in this case I would recommend to try to isolate that code in a seperate class where you can use

using System;

. Here I would avoid using the UnityEngine namespace and If I really need something from there I would be explicit there. Using alias names does not help the readabililty of a source file. Especially when you start listing several things explicitly

Code (CSharp):

1. using Object = UnityEngine.Object;
2. using Random = UnityEngine.Random;

The worst thing they added to C# is the using static statement. It suddenly pulls out static methods and properties into the local scope which can be quite a mess. I've seen code that used that quite a lot. It can be really confusing. For example by doing

using static Mathf;

you put everything in Mathf into your local file scope. It becomes real fun when ppl create their own methods and then use this.Method everywhere because they introduced ambiguity. Just keep it simple and as clear as possible.

 

A good summary, particularly for the sake of other readers, although I would not agree with all of it.. I know the first time you get hit with that error it's pretty confusing, and it's helpful to lay out a strategy for dealing with it.

My strategy is different. I divide my code into 'Unity' (which gets UnityEngine and Mathf and no System), and 'not Unity' (which gets the reverse including Math). There are lots of name conflicts scattered through the libraries, and trying to mix them and then add namespaces to sort them out is asking for trouble. Don't get me started on Point and Rect and Matrix etc.

So I use MS units tests, lots of LINQ and Func/Action and static Math in the 'non-Unity', but never in the 'Unity'. I have an extension library carefully written so I can use it in other projects. It keeps the code short, portable and readable, at least for me.