Short namespace heuristics for Autocomplete

[aparajit-pratap]

When there are namespace collisions, i.e. the same class name belonging to more than one namespace that are imported into Dynamo (via Import Library, Package manager, etc.), auto-complete would display the conflicting classes with their fully qualified names in order to distinguish them uniquely. For example:

Autodesk.DS.Geometry.Point
Rhino.Geometry.Point
FFITarget.Dynamo.Point

This submission enhances this experience by displaying the shortest possible names, such that they can still be resolved uniquely. So for the same example above, auto-complete now displays:

Autodesk.Point
Rhino.Point
FFITarget.Point

The core algorithm basically computes all possible in-order permutations of the individual namespaces in the long name and checks for which of these permutations, starting with the shortest, resolves uniquely. These shortest names are then fed into auto-complete to display instead of the fully qualified names used earlier.

Note that in the case of an existing resolution map in the namespace resolver, where there could be existing mappings to map say Point to Autodesk.DS.Geometry.Point, auto-complete will refer to the resolver as well. Thus in the same example above, it will display:

Point
Rhino.Point
FFITarget.Point

Unfortunately in the case of namespace collisions, users will need to get in the habit of seeing at least one namespace preceding the class name. We cannot get rid of them entirely.

Reviewers:
@Benglin
@junmendoza

[Benglin]

Hi @junmendoza please have a look at this, and I'll be back to see it later. Thanks :)

[aparajit-pratap]

Since most developers are busy or out of action, @sharadkjaiswal please give this a look. Thanks.

[junmendoza]

was there a specific reason to use an overload op as opposed to a normal function name?

[aparajit-pratap]

Well that's a C# thing (best practice) to overload the equality operator if you're overriding object.Equals so that both methods have the same behavior for the given type so as not to confuse users of that type.

[sharadkjaiswal]

I think it's the other way, when you are overloading operator ==, you must override object.Equals. If you have overridden object.Equals then even if you don't overload operator ==, it should call object.Equals internally.
https://msdn.microsoft.com/en-us/library/7h9bszxx(v=vs.85).aspx

[aparajit-pratap]

No equality operator does not know about object.Equals as it is purely a C# thing and has not got anything to do with .NET, which is what defines object.Equals. Equality operator does not use object.Equals internally.

[junmendoza]

Unless my comments reveal somthing glaring... LGTM

[aparajit-pratap]

Thanks @junmendoza!

[Benglin]

Thanks for helping to review, @junmendoza!