Avoid Language Gumbo
Wow! The "language gumbo" brainteaser created a lot of traffic! Patrick was first, but most people figured out that it was related to overload resolution rules differing between C# and VB.NET. Basically, when the client code calls g.Relax("MSCOREE"), the C# compiler looks for a matching method in the most derived type first, taking into account conversion (such as the one from string to object). As a result, it binds to the void Geek::Relax(object) method. The VB.NET compiler looks at all the overloads in the inheritance heirarchy for the 'best' match, and ends up binding to void Person::Relax(string).
The meta-question is actually the interesting part: why is this the case? The answer lies in section 9.2, Partition I of the ECMA-335 specification, where it says "The CTS, while it describes inheritance, object layout, name hiding, and overriding of virtual methods, does not discuss overloading at all. While this is surprising, it arises from the fact that overloading is entirely handled by compilers that target the CTS and not the type system itself. In the metadata, all references to types and type members are fully resolved and include the precise signature that is intended. This choice was made since every programming language has its own set of rules for coercing types and the VES does not provide a means for expressing those rules.".
For example, this is the reason that languages like C++ can offer scope resolution operators and C# doesn't, and that the different languages may offer different overload resolution rules. The implication is that just because your compiler produces CTS metadata, it doesn't mean that you can completely ignore what languages your clients are going to use. Note that this is still much better than the old C++ and COM stories where we had to ship source files or IDL/TLBs, but we're not yet at the point where component developers can completely ignore their client's choice of source languages.
The reason I like the example is that it's deceptively simple: both compilers make (arguably) reasonable decisions, but unfortunately, they are different decisions.
So what does this mean for you? If you're a component vendor or business developer producing class libraries/components for consumption by other developers/teams within your organization, you need to:
a) be aware of the sharp edges of cross-langauge integration and avoid them where-ever possible; and
b) include tests using your component from other languages in your test matrix.
This is one of the reasons that I counsel people to "avoid language gumbo". Just because you can build an application using 15 different languages, doesn't mean that you should - as always, developers need to understand the real capabilities and limitations of their platform and tools, and choose your battles wisely. [Peter Drayton's Radio Weblog]
8:01:59 PM 
|
|
