Share via

Req21: Allow unambiguous types from ambiguous namespaces

  • Article

[This post is part of a series, "wish-list for future versions of VB"]

 

IDEA: Allow unambiguous types from ambiguous namespaces. This request arises from VB's powerful "import" feature, which is more flexible than that of C#, but which introduces problems. I'll explain by example:

        Dim x As ComponentModel.INotifyPropertyChanged

        ' In Winforms apps, this is ambiguous

        ' between System.ComponentModel and System.Windows.Forms.ComponentModel

 

If you write this code in a Console app then it compiles fine. But if you write it in a Winforms app then it's a compile-time ambiguity error. That's because Winforms apps import both "System" and "System.Windows.Forms", and the compiler doesn't know whether the prefix "ComponentModel" means System.ComponentModel or System.Windows.Forms.ComponentModel.

 

It makes VB fragile against the framework introducing new types or namespaces.

 

IDEA: VB should allow "X.Y.Z" whenever the full name "X.Y.Z" is unambiguous (even if the prefix "X.Y" is ambiguous).

 

Here are some other examples: 

 

        Threading.Thread.Sleep(1000)

        ' In WPF aps, this is ambiguous

        ' between System.Threading and System.Windows.Threading

        Dim y As Xml.Linq.XDocument

        ' If you import System.Security.Cryptography, this is ambiguous

        ' between System.Xml and System.Security.Cryptography.Xml

 

It's not clear if this idea should work for ambiguous namespace and class prefixes, or merely for ambiguous namespace prefixes.

 

Provisional evaluation from VB team: We agree that this is a problem that would be good to fix. However, the spec rules for "unqualified and qualified name lookup" are already baffling ($4.7 and $11.4.4). This proposal would complicate them yet further. We will only consider this if we get clear and unambiguous feedback from users that they want the feature.

Comments

  • Anonymous
    February 15, 2010
    "VB should allow "X.Y.Z" whenever the full name "X.Y.Z" is unambiguous (even if the prefix "X.Y" is ambiguous)." This is a great idea. Don't worry about the spec being hard to read. Please don't ever prefer a more readable langauge spec over more readable programs :)

  • Anonymous
    February 16, 2010
    I’d like to see it. It may complicate the spec, but it’s what people would naturally expect the behaviour to be (I was surprised by this limitation when I encountered it first). Surely it’s better to match people’s expectations than to worry about the purity of the spec (within reason).

  • Anonymous
    February 17, 2010
    This should definately be done! It doesn't suit VB well to ramble about ambiguous namespaces even though the class is unambiguous. The current behavior doesn't fit to VB's usually more "relaxed" way of doing things.